Re: Add Python3 support to python-support packages: howto?
[Sandro Tosi, 2010-09-16] > From recent uploads, it seems that a proper python3 stack (i.e. > interpreter, -default and helper tools) is still a work-in-progress: > am I wrong on this? can we start to provide third-party modules py3k > binary packages without having to change several other times how the > packaging is done? If it's still and on-going effort, do you have any > estimate when it will converge to a usable state? ask release managers to announce freeze few months in advance next time instead of *after* the freeze (so that *all* transitions can be planned in a sane way) and then I will not ask you to test things written last night (yeah, I have day job and real life as well) You can always postpone your work until after Squeeze release. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100916072607.ge15...@piotro.eu
Re: Add Python3 support to python-support packages: howto?
On Thu, Sep 16, 2010 at 09:26, Piotr Ożarowski wrote: > [Sandro Tosi, 2010-09-16] >> From recent uploads, it seems that a proper python3 stack (i.e. >> interpreter, -default and helper tools) is still a work-in-progress: >> am I wrong on this? can we start to provide third-party modules py3k >> binary packages without having to change several other times how the >> packaging is done? If it's still and on-going effort, do you have any >> estimate when it will converge to a usable state? > > ask release managers to announce freeze few months in advance next time > instead of *after* the freeze (so that *all* transitions can be planned > in a sane way) Like if they're going to listen to me... (but that's OT in regards to my question) > and then I will not ask you to test things written last > night (yeah, I have day job and real life as well) That's not a problem. What I want to know is if the guide you wrote is already working and stable or not, and so if we can prepare py3k packages that will not require further change in a matter of days (or so). From your reply, I can infer the answer is 'no', which is fine, since I just wanted to know that :) > You can always postpone your work until after Squeeze release. If you want to use this argument, than this questions quickly arise: why is having python3 packages in squeeze pushed so hard when we don't have yet a stable and working workflow? Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlktim1+propsaysudwuhod9w1ktfx8hm2aft+jw...@mail.gmail.com
Re: Add Python3 support to python-support packages: howto?
[Sandro Tosi, 2010-09-16] > On Thu, Sep 16, 2010 at 09:26, Piotr Ożarowski wrote: > > and then I will not ask you to test things written last > > night (yeah, I have day job and real life as well) > > That's not a problem. What I want to know is if the guide you wrote is > already working yes, it's working. You can even test it with python3.2 from experimental (run f.e. `py3compile -V 3.2 -p python3-foo` as root - py3compile will ignore list of supported versions if version is listed explicit) > and stable or not I still want to make few changes, f.e. convince (i.e. prepare patches) debhelper maintainer to invoke dh_pytho3 for all python3-foo packages¹ by default or build extensions for all `py3versions -rv` versions if python3-all* is a build dependency. CDBS needs some love as well. [¹] dh_pysupport and dh_pycentral ignores them already, dh_python3 ignores python-foo (but there are possible conflicts with handling private directories, so I don't want to have dh_python3 enabled for all binary packages by default) > > You can always postpone your work until after Squeeze release. > > If you want to use this argument, than this questions quickly arise: > why is having python3 packages in squeeze pushed so hard when we don't > have yet a stable and working workflow? it's explained in mail sent by Matthias. Without changes at least in pythoh3.1 and python3-defaults, it will be much harder to support Python 3 in Wheezy (and if RMs will not accept them, it would be better to not support Python 3 in Squeeze at all, IMHO) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100916161531.gj15...@piotro.eu
Re: Python3 experimental packages with destination squeeze
Hello, On Wed, Sep 15, 2010 at 01:53, Matthias Klose wrote: > In experimental you'll find a set of packages for Python3 > > python3.1 3.1.2+20100909-1 > python3.2 3.2~a2-4 > python3-defaults 3.1.2-10 > python-defaults 2.6.6-2 > distribute 0.6.14-3 > > The python3.2 package has the PEP's 3147 (PYC Repository Directories) > [1] and 3149 (ABI version tagged .so files) [2] implemented, which > allows installation of .so and .py[co] files for different python > versions in one directory. The above packages do use a common > directory as the site directory for "public" packages > (/usr/lib/python3/dist-packages). distutils and distribute/setuptools > are patched to install into this site directory by default when using > the --install-layout=deb option. dh_python3 knows how to handle these > locations. When building packages, a build dependency on a minimum > version 3.1.2-10~ for one of the python3-* packages is needed. > > The part of PEP 3149 for looking up .so files with the ABI version is > backported to python3.1. > > Currently there are only a few packages in the archive depending on > python3, some of which already use the new location, I'd like to see > the rest of the packages converted too, so that these few packages can > ship with squeeze. > > * beaker 1.5.4-3 > * mako 0.3.4-4 > * sqlalchemy 0.6.4-2 > * markupsafe 0.11-2 > * jinja2 2.5.2-3 > * distribute 0.6.14-2 > * pycxx 6.2.0-3 > * gearman-interface > * lxml 2.2.8-1 > * python3-httplib2 > * python-slimmer > * pyyaml > * python-bsddb3 4.8.3-2 > * python-apt (python3-apt binary package is missing) > > Packages mentioned here with version numbers are already updated, in > experimental, in NEW, or being uploaded (Scott will care about pyaml, > Piotr will care about the remaining ones, I'll contact the python-apt > maintainers about the python-apt split). > > A small howto for packaging with python3 can be found here [3]. There > is a freeze exception/pre-approval granted by the release team [4] for > new "popular" binary python3-* packages as long as these are built > from the same source and don't introduce new upstream versions. Something I didn't find written anywhere and makes me wonder is: what's the gain for squeeze to have those new packages? is 3.1 being a supported version depending on those packages or viceversa? (after all, why have 3.1 as supported without any modules?) We are quite late in the release cycle, so what's the advantage to have all this work rushed to be included in squeeze? Some of the above mentioned py3k packages have such a low popcon they don't even worth to be mentioned (slimmer, bsddb3, and then gearman-interface that has 0 popcon), and the others are unluckily to be used "alone" but much more probably they are part of some bigger applications (scripts) and so unless you convert a lot more packages and the apps themselves, when the converted packages will be used? Also python3 does not have yet a stable workflow (that means interpreter, dh_python3, debhelper, python-support, etc etc receive continue uploads to fix that, introduce a new feature for py3k pkgs, and so on) and so I can't see the point in just throwing a bunch of modules converted with 2to3 into the release. Upstreams are releasing their codes compatible with both 2.x and 3.x, but it's a slow process. If it just a prove of concept, then why not skipping squeeze and wait for a much wider adoption of py3k in the world (so with proper, upstream-checked python3-compatible modules released) and postpone this for wheeze? I hope you can clear my doubts. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlktimzf_vkrrxquhuvm0uffbu5hxxvsnwvptbw4...@mail.gmail.com
Re: Python3 experimental packages with destination squeeze
[Sandro Tosi, 2010-09-16] > Something I didn't find written anywhere and makes me wonder is: > what's the gain for squeeze to have those new packages? is 3.1 being a > supported version depending on those packages or viceversa? (after > all, why have 3.1 as supported without any modules?) Please read PEP 3147 and PEP 3149 - that's what we'll have in Wheezy. 3149 (but *not* 3147) was partially backported to python3.1 so that both versions can share "dist-packages" directory. This means replacing 3.1 with 3.2 in Wheezy will be a lot easier and the toolchain will not have to support one exception¹ for Python 3.1 (3.0 was never supported by Debian). Few existing Squeeze packages that *do* support Python 3.1 right now would benefit from binNMU or few minor changes (changes in python3.1 are backwards compatible, BTW). We simply want to have toolchain ready in Squeeze, it has nothing to do with adding more python3-foo binary packages in Squeeze which is a separate thing. In Wheezy+1² we might have a problem with supporing more than one Python 3 version at the same time (in very rare cases where .py files cannot be shared or patched) but I'm convinced that by that time release managers will tell us about the freeze 6 months in advance and we'll figure something out with upstream. [¹] which would be a PITA, I removed like half of dh_python3 after moving files from /usr/lib/python3.1/dist-packages to /usr/lib/python3/dist-packages [²] yes, Wheezy+1, not Squeeze+1 -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20100916181218.ga26...@piotro.eu
