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). > - 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. 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
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com