=== Dios is now known as Guest27330 === yofel_ is now known as yofel === deegee_1 is now known as deegee === Dios is now known as Guest68538 [17:03] Hy all [17:03] hello [17:04] It a hungarian room?:D [17:05] This is not, no.. This is for classes to be taught.. [17:06] I mean [17:08] from what? [17:09] If you look in the topic there is a link to the course schedules in here... === cjohnston changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Classroom sessions now finished || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Thu Jan 21 2010 @ 20:00 UTC: Python Applications Packaging; Sat Jan 23 2010 @ 12:00 - 3:00 (Sun) UTC: Ubuntu User Day || Run 'date -u' in a terminal to find out the UTC time [20:03] so, who's here for Python Application Packaging session? :) [20:05] cjohnston should, at least ;) [20:06] huh who what [20:06] 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] ok, wait is over, I think we can start [20:11] Hello everybody, and thank you to be here at Python Application packaging session! [20:11] 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] We will discuss basic packaging today, we will face some in-depth implementation details next week at Ubuntu Developer Week. [20:12] 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] DktrKranz: I hate to break this to you, but you're a week early. [20:12] No he isn't [20:12] He's not? [20:12] He has a class scheduled toda [20:13] today [20:13] seperate from UDW [20:13] Oh, sorry. [20:13] ;-) [20:13] np [20:13] soren: no, I have two sessions, one today for PackagingTraining, and another one on Wed next week :) [20:13] Ok, sorry. [20:13] no [20:13] *np [20:14] 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] 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] But how does a Python application look like? [20:15] 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] 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] It's probably the smallest Python application you'll ever seen, it just prints a message, and then exits :) [20:17] Invest a couple of minutes to examine the few files available, then we will move to packaging, unless you have questions. [20:19] Any questions so far? [20:20] Ok, moving forward then. [20:20] 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] 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] 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] 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] .py files haven't to be compiled, so we don't need anything from Python -dev packages. [20:23] 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] Patch to Lintian is mine, so expect bugs from that check :P [20:24] 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] If you omit it, your package will be targeted for every supported Python version currently available, pyversions -s shows you which ones. [20:26] 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] 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] Any questions? [20:31] Ok, moving to the most crucial part. Which are dependencies for our Python software? [20:31] 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. === cjohnston is now known as notcjohnston [20:32] 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] 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] Go and download it somewhere, and let's use it on pythontest to see which its dependencies are. [20:35] Now, enter pythontest-0.1 directory and launch "python /where/you/downloaded/find_python_dependencies.py ." (do not forget dot!). === notcjohnston is now known as cjohnston [20:36] It will run for a bit, produce some error warnings you can ignore, and the most interesting part: our dependencies :) [20:36] Output should be very similar to http://people.debian.org/~dktrkranz/pythontest/output . [20:37] 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] 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] It usually provides a much longer list, but I already told you this is the smallest Python application you'll ever seen :) [20:39] 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] 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] QUESTION: what do the tuple values represent? [20:40] 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] 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] ah, ok [20:42] where is it getting the list from? something like apt-file, or does it have a static list? [20:43] dpkg -S [20:43] that way, it's slower, but much more reliable [20:43] ok [20:44] {'distutils.core': ('python2.5', 1), [20:44] 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] very handy [20:45] It has a bug [20:46] 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] Patches are welcome :) [20:47] Any other question? [20:48] that's all for now [20:49] 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] 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] If you like old debhelper style, you have to remember to pass --root and --prefix options to "python setup.py install" call [20:53] This way, file will be installed in the right locations, and both python2.6 and python2.5 will be fine. [20:54] 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] That option will override default distutils behaviour in python2.6 to fit Debian packaging. [20:56] Any questions? [20:58] do python apps get installed /usr/share/python2.x too? [20:58] or just libs [21:00] 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] ok, I'll make sure I'm around for that [21:00] thanks [21:00] 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] I hope so too [21:01] I'll be around if you have additional questions, or sponsoring requests :P [21:02] I hope you enjoyed the session, thanks for coming! [21:02] sponsoring? [21:02] I'm currently trying to package pysolfc (see LP #179298 and debian #519752) [21:02] Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298 [21:02] Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298 [21:02] Debian bug 519752 in wnpp "RFP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] http://bugs.debian.org/519752 [21:02] Debian bug 519752 in wnpp "RFP: pysolfc -- A Python solitaire game collection" [Wishlist,Open] http://bugs.debian.org/519752 [21:02] Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298 [21:02] Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298 [21:02] Launchpad bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] [21:02] Ubuntu bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] [21:02] Ubuntu bug 179298 in ubuntu "[needs-packaging] pysolfc missing from repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/179298 [21:03] bot wars [21:03] oops [21:03] Right now, I'm using a cdbs and pysupport based and rather minimal rules file [21:03] wow! :) [21:04] 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] DktrKranz: okay, thx for the hint. can i still ask you something? [21:05] I can look at it if you have something ready already (but better moving to a private channel for sponsoring requests) [21:05] i'd like to override the destination for some files [21:05] are they installed by distutils, or similar? [21:05] yeah [21:06] currently, they go to /usr/share/PySolFC [21:06] 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] (but it's a game, i think they belong to /usr/share/games/pysolfc) [21:07] /usr/games, usually [21:07] sure? there's binaries, mostly, while /usr/share/games contains some game data files [21:08] ah, you want the whole directory to be moved under /usr/share/games [21:09] yeah, it's just some game data -- cardsets etc [21:09] 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] then you can pass --install-lib=/usr/share/games/PySolFC to setup.py install call [21:10] if setup.py handles "packages", you should be fine [21:10] i think i had that already, but that caused pixmap/icons/desktop directories there, too [21:10] * to go there, too [21:11] you can use data_files instead of packages in setup.py for those [21:11] and let directories with Python modules managed by packages directive [21:13] e.g. see http://bazaar.launchpad.net/~dktrkranz/debomatic/debomatic.dev/annotate/head%3A/setup.py [21:15] okay, so it's mostly patching setup.py [21:15] hm... but i think i still need to tweak the rules file [21:15] the script is called pysol.py, though it should be renamed to pysolfc [21:15] can you tell me how to do that? [21:16] you can use a symlink for it, it's common practice [21:16] and put it in /usr/games, for instance [21:16] else, you will have to mv it in rules. [21:17] yeah, thats were it already goes because of DEB_PYTHON_INSTALL_ARGS_ALL += --install-scripts=/usr/games [21:17] yeah, that's the other powerful and wide-used distutils variable :) [21:18] 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] use debian/links [21:19] okay, i guess that's basically it for the python related stuff. thanks! [21:20] np, feel free to drop me a line for a deeper review :) [21:20] cool! === pleia2 changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Classroom sessions now finished || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Sat Jan 23 2010 @ 12:00 - 3:00 (Sun) UTC: Ubuntu User Day; Mon 25 Jan - Fri 29 Jan 2010: Ubuntu Developer Week || Run 'date -u' in a terminal to find out the UTC time === pleia2 changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Sat Jan 23 2010 @ 12:00 - 3:00 (Sun) UTC: Ubuntu User Day; Mon 25 Jan - Fri 29 Jan 2010: Ubuntu Developer Week || Run 'date -u' in a terminal to find out the UTC time === alexbobp_ is now known as alexbobp