[17:03] <Hammer> Hy all
[17:03] <cjohnston> hello
[17:04] <Hammer> It a hungarian room?:D
[17:05] <cjohnston> This is not, no.. This is for classes to be taught..
[17:06] <Hammer> I mean
[17:08] <Hammer> from what?
[17:09] <cjohnston> If you look in the topic there is a link to the course schedules in here...
[20:03] <DktrKranz> so, who's here for Python Application Packaging session? :)
[20:05] <DktrKranz> cjohnston should, at least ;)
[20:06] <cjohnston> huh who what
[20:06] <DktrKranz> let's wait some more minutes for more people to come, and then start the session
[20:07]  * cjohnston does want to learn python...
[20:10] <DktrKranz> ok, wait is over, I think we can start
[20:11] <DktrKranz> Hello everybody, and thank you to be here at Python Application packaging session!
[20:11] <DktrKranz> My name is Luca Falavigna, I'm a MOTU and Debian Developer, and I'll be your SABPDFT (Self-Appointed Benevolent Python Dictator For Today) for the next minutes :)
[20:11] <DktrKranz> We will discuss basic packaging today, we will face some in-depth implementation details next week at Ubuntu Developer Week.
[20:12] <DktrKranz> In this session, we will see how to package and maintain Python applications easily, so let's start with a really short introduction.
[20:12] <soren> DktrKranz: I hate to break this to you, but you're a week early.
[20:12] <cjohnston> No he isn't
[20:12] <soren> He's not?
[20:12] <cjohnston> He has a class scheduled toda
[20:13] <cjohnston> today
[20:13] <cjohnston> seperate from UDW
[20:13] <soren> Oh, sorry.
[20:13] <cjohnston> ;-)
[20:13] <cjohnston> np
[20:13] <DktrKranz> soren: no, I have two sessions, one today for PackagingTraining, and another one on Wed next week :)
[20:13] <soren> Ok, sorry.
[20:13] <DktrKranz> no
[20:13] <DktrKranz> *np
[20:14] <DktrKranz> I refer to a "Python application" as a piece of software composed by one or more Python scripts and eventually one of more modules (or "packages", distutils calls them that way).
[20:14] <DktrKranz> Other kinds of software are "Python modules", which contain modules potentially useful for other programs, and "Python extensions", which usually are C source files, compiled and liked for a given Python interpreter to extend its features.
[20:15] <DktrKranz> But how does a Python application look like?
[20:15] <DktrKranz> I've created a really dumb one for the occasion. Open your favourite terminal and launch dget -u http://people.debian.org/~dktrkranz/pythontest/pythontest_0.1-1/pythontest_0.1-1.dsc
[20:16] <DktrKranz> Once you've downloaded it, look at pythontest-0.1 directory, you will find pythontest script, PythonTest module (or "package") and setup.py, which is Python distutils' "makefile".
[20:16] <DktrKranz> It's probably the smallest Python application you'll ever seen, it just prints a message, and then exits :)
[20:17] <DktrKranz> Invest a couple of minutes to examine the few files available, then we will move to packaging, unless you have questions.
[20:19] <DktrKranz> Any questions so far?
[20:20] <DktrKranz> Ok, moving forward then.
[20:20] <DktrKranz> OK, now moving to debian directory/, its structure is quite straigthforward, I added some examples and comments to ease your job if you like CDBS or old-style debhelper.
[20:21] <DktrKranz> The most important files right now are control and rules, they must contain some peculiar things for Python, let's see them together.
[20:21] <DktrKranz> control has some comments to ease your job, but you should usually pay attention to Build-Depends, XS-Python-Version field and Depends.
[20:22] <DktrKranz> One of the common "mistakes" is build-depending on python-dev or python-all-dev while having only .py files (as this application provides). Well, it's not a mistake per-se, but it's a waste of resources.
[20:22] <DktrKranz> .py files haven't to be compiled, so we don't need anything from Python -dev packages.
[20:23] <DktrKranz> Starting from version 2.3.0, lintian complains about that, so hopefully maintainers will take care of fixing packages (there are a *lot*: http://lintian.debian.org/tags/build-depends-on-python-dev-with-no-arch-any.html ).
[20:24] <DktrKranz> Patch to Lintian is mine, so expect bugs from that check :P
[20:24] <DktrKranz> Next interesting line is XS-Python-Version. This instruct Python helper tools (python-central or python-support) to byte-compile files for the desired versions, and expands ${python:Depends} to the correct value, so you don't have to manage dependencies to the Python interpreter anymore.
[20:25] <DktrKranz> If you omit it, your package will be targeted for every supported Python version currently available, pyversions -s shows you which ones.
[20:26] <DktrKranz> I recommend you to always mention it, it will help a lot during transitions between a Python version to another, and it immediately shows compatibility between versions.
[20:27] <DktrKranz> debian/pyversions does the same thing as XS-Python-Version (with a different syntax), but it's specific to python-support, while XS-Python-Version is common to both (even if it's not the preferred way in python-support). It's up to you to choose what you like more.
[20:28] <DktrKranz> Any questions?
[20:31] <DktrKranz> Ok, moving to the most crucial part. Which are dependencies for our Python software?
[20:31] <DktrKranz> This is often hard to say, because scripts usually include a lot of modules, many of them already in Python standard library, while some others are provided via stand-alone packages.
[20:32] <DktrKranz> You can browse Python documentation to see if a module is already provided by Python directly, ask Google, or whatever. But it's a lot of work, a lot of time spent, and a boring task, so I propose you a different approach.
[20:33] <DktrKranz> In Debian, we created a wonderful script which does most part of the job: http://svn.debian.org/viewsvn/python-modules/tools/find_python_dependencies.py
[20:33] <DktrKranz> Go and download it somewhere, and let's use it on pythontest to see which its dependencies are.
[20:35] <DktrKranz> Now, enter pythontest-0.1 directory and launch "python /where/you/downloaded/find_python_dependencies.py ." (do not forget dot!).
[20:36] <DktrKranz> It will run for a bit, produce some error warnings you can ignore, and the most interesting part: our dependencies :)
[20:36] <DktrKranz> Output should be very similar to http://people.debian.org/~dktrkranz/pythontest/output .
[20:37] <DktrKranz> What does it say to us? First dictionary represents modules it already found available on the system, the second those he didn't, or was unable to parse.
[20:37] <DktrKranz> In our case, it discovered distutils.core and os (they're part of Python standard library, so they're already available), and keybinder (which you probably don't have).
[20:38] <DktrKranz> It usually provides a much longer list, but I already told you this is the smallest Python application you'll ever seen :)
[20:39] <DktrKranz> All you have to do is go through this list, and add modules to your Depends line. You can forget about python2.X and python2.X-minimal, they will be provided by python-{support,central} (as we saw some minutes ago), but you have to list the others.
[20:39] <DktrKranz> Python policy states Debian Python modules packages should be named python-modulename, so it should be easy to guess which package "keybinder" module belongs :)
[20:39] <mhall119|work> QUESTION: what do the tuple values represent?
[20:40] <DktrKranz> Of course, this script is only meant to *help*, not to do all the work, so you're asked to double-check these results, but it's usually very good.
[20:41] <DktrKranz> mhall119|work: the first value says which package a given module belongs (or error message in case it didn't found any), the second is numver of times a given module is found in the sources
[20:41] <mhall119|work> ah, ok
[20:42] <mhall119|work> where is it getting the list from?  something like apt-file, or does it have a static list?
[20:43] <DktrKranz> dpkg -S
[20:43] <DktrKranz> that way, it's slower, but much more reliable
[20:43] <mhall119|work> ok
[20:44] <DktrKranz> {'distutils.core': ('python2.5', 1),
[20:44] <DktrKranz> distutils.core is module name, python2.5 the package where the module is found (you probably have python2.6 here), and 1 is the number of times module is found
[20:45] <mhall119|work> very handy
[20:45] <DktrKranz> It has a bug
[20:46] <DktrKranz> it looks for *.py files only, it does not search for files with a #!/usr/bin/python shebang, so you will have to manually inspect those.
[20:46] <DktrKranz> Patches are welcome :)
[20:47] <DktrKranz> Any other question?
[20:48] <mhall119|work> that's all for now
[20:49] <DktrKranz> Finally, let's have a look at rules, I prepared three of them to fit everyone's tastes (dh7, cdbs, and old-style debhelper). Open the one you are more familiar with.
[20:51] <DktrKranz> Not much to say, and much to write in those, usually setup.py manages things in a good way, and python-support and python-central do the rest.
[20:52] <DktrKranz> If you like old debhelper style, you have to remember to pass --root and --prefix options to "python setup.py install" call
[20:53] <DktrKranz> This way, file will be installed in the right locations, and both python2.6 and python2.5 will be fine.
[20:54] <DktrKranz> If strictly needed --install-layout=deb option should be passed too, this is because python2.6 changed directory where modules are stored, from /usr/share/python2.X/site-packages to /usr/local/share/python2.6/dist-package, and we don't want files in /usr/local :)
[20:55] <DktrKranz> That option will override default distutils behaviour in python2.6 to fit Debian packaging.
[20:56] <DktrKranz> Any questions?
[20:58] <mhall119|work> do python apps get installed /usr/share/python2.x too?
[20:58] <mhall119|work> or just libs
[21:00] <DktrKranz> mhall119|work: Yes, they are. /usr/share is a private directory, not accessible by Python directly, so additional care must be used. This will be handled in the next week session in detail.
[21:00] <mhall119|work> ok, I'll make sure I'm around for that
[21:00] <mhall119|work> thanks
[21:00] <DktrKranz> Ok, so we can conclude this session, I'll take one next week at Ubuntu Developer Week about some advanced techniques in Python packaging, I hope to see you there :)
[21:01] <mhall119|work> I hope so too
[21:01] <DktrKranz> I'll be around if you have additional questions, or sponsoring requests :P
[21:02] <DktrKranz> I hope you enjoyed the session, thanks for coming!
[21:02] <mhall119|work> sponsoring?
[21:02] <ockham> I'm currently trying to package pysolfc (see LP #179298 and debian #519752)
[21:02] <ubot2> Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298
[21:02] <ubot2> Debian bug 519752 in wnpp "RFP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] http://bugs.debian.org/519752
[21:02] <ubot2> Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298
[21:02] <ubot2> Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed]
[21:02] <ubot2> Ubuntu bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298
[21:03] <mhall119|work> bot wars
[21:03] <ockham> oops
[21:03] <ockham> Right now, I'm using a cdbs and pysupport based and rather minimal rules file
[21:03] <DktrKranz> wow! :)
[21:04] <DktrKranz> ockham: in Debian, we have two teams which take care of sponsoring Python applications and modules, they're usually quick and very good.
[21:05] <ockham> DktrKranz: okay, thx for the hint. can i still ask you something?
[21:05] <DktrKranz> I can look at it if you have something ready already (but better moving to a private channel for sponsoring requests)
[21:05] <ockham> i'd like to override the destination for some files
[21:05] <DktrKranz> are they installed by distutils, or similar?
[21:05] <ockham> yeah
[21:06] <ockham> currently, they go to /usr/share/PySolFC
[21:06] <DktrKranz> you have two ways: patching distutils or manually move them after python setup.py install call, and before dh_py{support,central} call
[21:06] <ockham> (but it's a game, i think they belong to /usr/share/games/pysolfc)
[21:07] <DktrKranz> /usr/games, usually
[21:07] <ockham> sure? there's binaries, mostly, while /usr/share/games contains some game data files
[21:08] <DktrKranz> ah, you want the whole directory to be moved under /usr/share/games
[21:09] <ockham> yeah, it's just some game data -- cardsets etc
[21:09] <ockham> anyway, i think i'd like to go for the latter option, but i don't know how to override cdbs/pysupport's behavior - my rules file looks mostly like your rules.cdbs
[21:09] <DktrKranz> then you can pass --install-lib=/usr/share/games/PySolFC to setup.py install call
[21:10] <DktrKranz> if setup.py handles "packages", you should be fine
[21:10] <ockham> i think i had that already, but that caused pixmap/icons/desktop directories there, too
[21:10] <ockham> * to go there, too
[21:11] <DktrKranz> you can use data_files instead of packages in setup.py for those
[21:11] <DktrKranz> and let directories with Python modules managed by packages directive
[21:13] <DktrKranz> e.g. see http://bazaar.launchpad.net/~dktrkranz/debomatic/debomatic.dev/annotate/head%3A/setup.py
[21:15] <ockham> okay, so it's mostly patching setup.py
[21:15] <ockham> hm... but i think i still need to tweak the rules file
[21:15] <ockham> the script is called pysol.py, though it should be renamed to pysolfc
[21:15] <ockham> can you tell me how to do that?
[21:16] <DktrKranz> you can use a symlink for it, it's common practice
[21:16] <DktrKranz> and put it in /usr/games, for instance
[21:16] <DktrKranz> else, you will have to mv it in rules.
[21:17] <ockham> yeah, thats were it already goes because of DEB_PYTHON_INSTALL_ARGS_ALL += --install-scripts=/usr/games
[21:17] <DktrKranz> yeah, that's the other powerful and wide-used distutils variable :)
[21:18] <ockham> i guess i'm outing myself as the total newbie now, but i don't know where to insert this symlinking within this cdbs based rules file...
[21:18] <DktrKranz> use debian/links
[21:19] <ockham> okay, i guess that's basically it for the python related stuff. thanks!
[21:20] <DktrKranz> np, feel free to drop me a line for a deeper review :)
[21:20] <ockham> cool!