[Python-Dev] Bilingual scripts (original) (raw)

Barry Warsaw barry at python.org
Tue May 28 19:22:01 CEST 2013

On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:

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

Thanks. One of the reasons I've brought this up here is so that hopefully we can come up with recommendations for upstreams where this matters.

One thing is for sure (IMO, anyway). Utilities that provide version-specific scripts should also provide -m invocation. E.g. there are various places where a package's tests (provided unittest, or other as-built tests) can be invoked. Where those might use nose, we recommend invoking them with $python -m nose instead using nosetests-X.Y. This also makes it easier to loop over all the versions of Python available on the system (which might not be known statically).

- 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.]

Note that the Gentoo example also takes into account versions that might act differently based on the interpreter's implementation. So a -python3 suffix may not be enough. Maybe now we're getting into PEP 425 compatibility tag territory.

- (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). - easyinstall (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.

Yay.

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.

Same here. I definitely don't like the current Debian semi-convention (not standardized or consistent) of injecting a '3' in the middle of the name, e.g. py3compile or py3doc.

Note that adopting PEP 425 conventions allows for -py3 suffix to mean any Python 3 version, compatible across minor version numbers or implementations. This probably translates into a shebang line of

#! /usr/bin/python3

whereas -py33 would mean

#! /usr/bin/python3.3

This might be overkill in some cases, but at least it builds on existing standards.

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)

Definitely the former, especially if PEP 425 serves at the basis for standardization.

-Barry

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20130528/c105766b/attachment.pgp>

More information about the Python-Dev mailing list