=== 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 | ||
Hammer | Hy all | 17:03 |
---|---|---|
cjohnston | hello | 17:03 |
Hammer | It a hungarian room?:D | 17:04 |
cjohnston | This is not, no.. This is for classes to be taught.. | 17:05 |
Hammer | I mean | 17:06 |
Hammer | from what? | 17:08 |
cjohnston | If you look in the topic there is a link to the course schedules in here... | 17:09 |
=== 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 | ||
DktrKranz | so, who's here for Python Application Packaging session? :) | 20:03 |
DktrKranz | cjohnston should, at least ;) | 20:05 |
cjohnston | huh who what | 20:06 |
DktrKranz | let's wait some more minutes for more people to come, and then start the session | 20:06 |
* cjohnston does want to learn python... | 20:07 | |
DktrKranz | ok, wait is over, I think we can start | 20:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
DktrKranz | Invest a couple of minutes to examine the few files available, then we will move to packaging, unless you have questions. | 20:17 |
DktrKranz | Any questions so far? | 20:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
DktrKranz | If you omit it, your package will be targeted for every supported Python version currently available, pyversions -s shows you which ones. | 20:25 |
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:26 |
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:27 |
DktrKranz | Any questions? | 20:28 |
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:31 |
=== cjohnston is now known as notcjohnston | ||
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:32 |
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:33 |
DktrKranz | Now, enter pythontest-0.1 directory and launch "python /where/you/downloaded/find_python_dependencies.py ." (do not forget dot!). | 20:35 |
=== notcjohnston is now known as cjohnston | ||
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:36 |
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:37 |
DktrKranz | It usually provides a much longer list, but I already told you this is the smallest Python application you'll ever seen :) | 20:38 |
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:39 |
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:40 |
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:41 |
mhall119|work | where is it getting the list from? something like apt-file, or does it have a static list? | 20:42 |
DktrKranz | dpkg -S | 20:43 |
DktrKranz | that way, it's slower, but much more reliable | 20:43 |
mhall119|work | ok | 20:43 |
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:44 |
mhall119|work | very handy | 20:45 |
DktrKranz | It has a bug | 20:45 |
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:46 |
DktrKranz | Any other question? | 20:47 |
mhall119|work | that's all for now | 20:48 |
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:49 |
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:51 |
DktrKranz | If you like old debhelper style, you have to remember to pass --root and --prefix options to "python setup.py install" call | 20:52 |
DktrKranz | This way, file will be installed in the right locations, and both python2.6 and python2.5 will be fine. | 20:53 |
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:54 |
DktrKranz | That option will override default distutils behaviour in python2.6 to fit Debian packaging. | 20:55 |
DktrKranz | Any questions? | 20:56 |
mhall119|work | do python apps get installed /usr/share/python2.x too? | 20:58 |
mhall119|work | or just libs | 20:58 |
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:00 |
mhall119|work | I hope so too | 21:01 |
DktrKranz | I'll be around if you have additional questions, or sponsoring requests :P | 21:01 |
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 |
ubottu | 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 |
ubottu | 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 |
ubottu | 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 |
ubottu | Ubuntu 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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
DktrKranz | /usr/games, usually | 21:07 |
ockham | sure? there's binaries, mostly, while /usr/share/games contains some game data files | 21:07 |
DktrKranz | ah, you want the whole directory to be moved under /usr/share/games | 21:08 |
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:09 |
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:10 |
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:11 |
DktrKranz | e.g. see http://bazaar.launchpad.net/~dktrkranz/debomatic/debomatic.dev/annotate/head%3A/setup.py | 21:13 |
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:15 |
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:16 |
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:17 |
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:18 |
ockham | okay, i guess that's basically it for the python related stuff. thanks! | 21:19 |
DktrKranz | np, feel free to drop me a line for a deeper review :) | 21:20 |
ockham | cool! | 21:20 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!