I hope you don't mind me chiming in on a few relevant things from Debianland. On Dec 03, 2014, at 09:37 AM, Bohuslav Kabrda wrote: >In [3], it says "If the executables provide the same functionality >independent of whether they are run on top of Python 2 or Python 3, then only >one version of the executable should be packaged. Currently it will be the >python 2 implementation, but once the Python 3 implementation is proven to >work, the executable can be retired from the python 2 build and enabled in >the python 3 package." - this should be changed to prefer Python 3 Debian is doing this package by package. For example, /usr/bin/tox and /usr/bin/gtimelog are shebanged to /usr/bin/python3. >(This is not really related to the switch, but more of a general remark) In >[4], it says that "python 3 version of the executable gains a python3- >prefix". This is IMO bad, since upstream projects tend to name the >versioned binaries "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one >of these - I'm not really certain which one of them. I tried to discuss >this several times on distutils-sig mailing list, but without reaching a >consensus. Either way, prefixing with python3- doesn't make sense to me, >because it's not similar to any upstream way and you don't find the >binaries under their names using tab completion (e.g. foo<tab> doesn't tell >you about python3-foo). In general, we don't provide two versions of the binaries. You won't find a tox and tox-3 in /usr/bin. If we can provide a Python 3 version, and the package maintainer has switched over, you'll only find the Python 3 version. Users generally don't care what version Python their app runs on. There are a few exceptions, but these are limited to cases where it actually matters which version of Python the script runs. An example of this is nose and nose2. Because these invoke different Python executable environments, the shebang of these scripts does matter. E.g, we provide /usr/bin/nosetests (#!/usr/bin/python), /usr/bin/nosetests-2.7 (#!/usr/bin/python2.7), /usr/bin/nosetests3 (#!/usr/bin/python3). (Looks like we're missing one for 3.4, oh well.) In these cases, the naming convention can get tricky. Usually, as you suggest, the unversioned script is the Python 2 version, specifically #!/usr/bin/python (or less commonly #!/usr/bin/python2 for PEP 394 aficionados). foo-2.7 will be #!/usr/bin/python2.7 (we don't support anything older than that). foo-3 will be #!/usr/bin/python3 and foo-3.4 will be #!/usr/bin/python3.4. As you can see for nosetests-under-Python-3, we're not always consistent. Of course it gets a little trickier for things like nose2. nose2-3 is #!/usr/bin/python3. >While I still think it'd be great to do this change, it'll require a >significant effort and that is better spent helping upstreams to port to >Python 3 ATM. +1! Getting more upstreams on Python 3 helps all Pythonistas. Debian 8 (Jessie) is in release freeze now but after that is released I will be doing more work (along with others in our community) toward moving to a predominantly Python 3 world. We have a couple of Debian-only packages which are blocking a switch to Python3-installed-by-default and I'll be tackling those first (similarly in Ubuntu). The next step is making sure that for those upstreams that do support Python 3, that is available by default in the archive. Then I think it's a matter of trying to switch any other scripts which *can* run under Python 3, to do so. Cheers, -Barry
Attachment:
signature.asc
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
