[Python-Dev] Bilingual scripts

[Toshio Kuratomi]

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 ``pydoc3`` and ``pyvenv``). (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>