[Python-Dev] Bilingual scripts (original) (raw)
Toshio Kuratomi a.badger at gmail.com
Mon May 27 20:38:36 CEST 2013
- Previous message: [Python-Dev] Bilingual scripts
- Next message: [Python-Dev] Bilingual scripts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, May 25, 2013 at 05:57:28PM +1000, Nick Coghlan wrote:
On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw <barry at python.org> wrote: > Have any other *nix distros addressed this, and if so, how do you solve it?
I believe Fedora follows the lead set by our own makefile and just appends a "3" to the script name when there is also a Python 2 equivalent (thus
pydoc3andpyvenv). (I don't have any other system provided Python 3 scripts on this machine, though)
Fedora is a bit of a mess... we try to work with upstream's intent when upstream has realized this problem exists and have a single standard when upstream does not. The full guidelines are here:
http://fedoraproject.org/wiki/Packaging:Python#Naming
Here's the summary:
If the scripts don't care whether they're running on py2 or py3, just use the base name and choose python2 as the interpreter for now (since we can't currently get rid of python2 on an end user system, that is the choice that brings in less dependencies). ex: /usr/bin/pygmentize
If the script does two different things depending on python2 or python3 being the interpreter (note: this includes both bilingual scripts and scripts which have been modified by 2to3/exist in two separate versions) then we have to look at what upstream is doing:
If upstream already deals with it (ex: pydoc3, easy_install-3.1) then we use upstream's name. We don't love this from an inter-package consistently standpoint as there are other packages which append a version for their own usage (is /usr/bin/foo-3.4 for python-3.4 or the 3.4 version of the foo package?) (And we sometimes have to do this locally if we need to have multiple versions of a package with the multiple versions having scripts... ) We decided to use upstream's name if they account for this issue because it will match with upstream's documentation and nothing else seemed as important in this instance.
If upstream doesn't deal with it, then we use a "python3-" prefix. This matches with our package naming so it seemed to make sense. (But Barry's point about locate and tab completion and such would be a reason to revisit this... Perhaps standardizing on /usr/bin/foo2-python3 [pathological case of having both package version and interpreter version in the name.]
(tangent from a different portion of this thread: we've found that this is a larger problem than we would hope. There are some obvious ones like
- ipython (implements a python interpreter so python2 vs python3 is understandably important ad different).
- nosetests (the python source being operated on is run through the python interpreter so the version has to match).
- easy_install (needs to install python modules to the correct interpreter's site-packages. It decides the correct interpreter according to which interpreter invoked it.)
But recently we found a new class of problems: frameworks which are bilinugual. For instance, if you have a web framework which has a /usr/bin/django-admin script that can be used to quickstart a project, run a python shell and automatically load your code, load your ORM db schema and operate on it to make modifications to the db then that script has to know whether your code is compatible with python2 or python3.
> It would be nice if we could have some cross-platform recommendations so > things work the same wherever you go. To that end, if we can reach some > consensus, I'd be willing to put together an informational PEP and some > scripts that might be of general use.
It seems to me the existing recommendation to use ``#!/usr/bin/env python`` instead of referencing a particular binary already covers the general case. The challenge for the distros is that we want a solution that ignores user level virtual environments. I think the simplest thing to do is just append the "3" to the binary name (as we do ourselves for pydoc) and then abide by the recommendations in PEP 394 to reference the correct system executable. I'd rather not have a bare 3 for the issues notes above. Something like py3 would be better.
There's still room for confusion when distributions have to push multiple versions of a package with scripts that fall into this category. Should the format be:
/usr/bin/foo2-py3 (My preference as it places the version next to the thing that it's a version of.)
or
/usr/bin/foo-py3-2 (Confusing as the 2 is bare. Something like /usr/bin/foo-py3-v2 is slightly better but still not as nice as the previous IMHO)
-Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20130527/beaf739f/attachment.pgp>
- Previous message: [Python-Dev] Bilingual scripts
- Next message: [Python-Dev] Bilingual scripts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]