Hello, On Wed, Sep 15, 2010 at 01:53, Matthias Klose <d...@debian.org> 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
