Re: Packaging applications with extensions modules
* Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: - dh_python2 (which, for some reason, everyone wants to use) doesn't generate §3.1.1-compliant dependency for such setup. Yeah, we should fix that. Fix everyone, or just dh_python2? ; I've just filed #702677. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130310003504.ga6...@jwilk.net
Re: Packaging applications with extensions modules
Hi Jakub (2013.02.16_14:01:58_+0200) C) Built the modules only for the default Python version and install them to a private directory (/usr/lib/PKGNAME/ or similar). This is what Python Policy tells us to do. I see the following problem with this approach: This is my preferred approach, and I think we should deal with the problems. - You can ship extensions only for one Python version. (Arguably that's not a big deal.) Not a big deal because: * 2.7 is the end of 2 (we hope) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags * we don't tend to have more than one 3.x version in the archive for long (thanks to easy transitions, but they are sure to get harder) - Unless you write the code yourself, there is no protection against loading extensions modules for a wrong Python version. Not going to a problem with 3.x - dh_python2 (which, for some reason, everyone wants to use) doesn't generate §3.1.1-compliant dependency for such setup. Yeah, we should fix that. I don't think the problems with C are big enough to warrant changing the policy. I think the approach is fairly sound. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013013110.ga29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
* Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013014824.ga4...@jwilk.net
Re: Packaging applications with extensions modules
Hi Jakub (2013.02.22_23:48:24_+0200) * Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. If only the tags were applied applied before dh_python3 got there... SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013015209.gc29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
Stefano Rivera stefa...@debian.org wrote: Hi Jakub (2013.02.22_23:48:24_+0200) * Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. If only the tags were applied applied before dh_python3 got there... SR What's not supported? Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b0143391-e898-4dd0-919e-c02f3d9df...@email.android.com
Re: Packaging applications with extensions modules
Hi Scott (2013.02.23_00:17:30_+0200) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. What's not supported? Not all build systems append tags to the C extension file names, so if you install to the same directory in a pyversion loop, you may overwrite C extensions from earlier python versions. Not a problem for distutils, though. So, maybe that's only a very minor issue. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013023849.gd29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
Stefano Rivera stefa...@debian.org wrote: Hi Scott (2013.02.23_00:17:30_+0200) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. What's not supported? Not all build systems append tags to the C extension file names, so if you install to the same directory in a pyversion loop, you may overwrite C extensions from earlier python versions. Not a problem for distutils, though. So, maybe that's only a very minor issue. dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b601b85e-de8e-4811-b163-86a85807c...@email.android.com
Re: Packaging applications with extensions modules
* Scott Kitterman deb...@kitterman.com, 2013-02-22, 17:56: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) I gave it a try, and it appears to work, provided that upstream build system supports ABI tagging. Wow. :-) dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. If you install multiple non-tagged extensions to a private directory, they'll have overwritten each other before dh_python3 will have a chance to rename them. We'll have this problem also for build systems which install stuff to /usr/lib/python3/dist-packages/, but don't support PEP3149... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013032416.ga7...@jwilk.net
Re: Packaging applications with extensions modules
On Saturday, February 23, 2013 12:24:16 AM Jakub Wilk wrote: * Scott Kitterman deb...@kitterman.com, 2013-02-22, 17:56: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) I gave it a try, and it appears to work, provided that upstream build system supports ABI tagging. Wow. :-) dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. If you install multiple non-tagged extensions to a private directory, they'll have overwritten each other before dh_python3 will have a chance to rename them. We'll have this problem also for build systems which install stuff to /usr/lib/python3/dist-packages/, but don't support PEP3149... I think for most build systems you can override the install directory. For sip4, python-qt4, and friends I install in /buildx.y and then dh_python3 renames the files on move. You're correct that you can end up overwriting the files if you aren't careful. The worst thing I've seen this: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/raring/pykde4/raring/view/head:/debian/rules Certainly not the easiest thing in the world, but it works. BTW, there is no support at all for pure python3 code that's version specific. I had to do horrible things in sip4/python-qt4 to make that work. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2204074.jeqpeBvNHb@scott-latitude-e6320
Packaging applications with extensions modules
We[0] have a Python application, which includes Python modules that are not supposed to be used by any other software. Some of them are extension modules. What is the best way to package such applications? I can think of the following approaches: A) Install the modules to dist-packages. This is often what upstream supports, making it the cheapest solution. It's also well supported by Python helpers. Unlike some of the other methods, it allows shipping extension modules for multiple Python versions. The downside is that it causes namespace pollution, sometimes to the point it's completely unacceptable (like in the case of the package I'm having currently in mind). B) Like in A, install the module to dist-packages, but put them in a namespace clearly indicating that it is private, i.e. starting with an underscore. This has most of the advantages of A, with pollution reduced significantly. C) Built the modules only for the default Python version and install them to a private directory (/usr/lib/PKGNAME/ or similar). This is what Python Policy tells us to do. I see the following problem with this approach: - You can ship extensions only for one Python version. (Arguably that's not a big deal.) - Unless you write the code yourself, there is no protection against loading extensions modules for a wrong Python version. - dh_python2 (which, for some reason, everyone wants to use) doesn't generate §3.1.1-compliant dependency for such setup. D) Install the modules into a private, Python-version-specific directories (say /usr/lib/PKGNAME/python2.X/). This is a clever way of working around some problems with C. Unfortunately, unless upstream supports such setup (very unlikely), it requires patching every script. Worse, no Python helpers support this method, so you'd have to write maintainer scripts and generate dependencies yourself. I'm currently leaning towards B, although I'm not aware of any packages using this method, so I thought I'd ask here first. [0] We, the King of... er, wrong mail; let me try again: We, that is me and my sponsoree: http://bugs.debian.org/696782 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130216120158.ga3...@jwilk.net
