Re: [Fedora-packaging] Changes in Guidelines Connected to "Python 3 as Default" Change

[Toshio Kuratomi]

On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
>  
>  On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda(a)redhat.com&gt; wrote:
>  >
>  > So here are my proposals for changes in current guidelines [2]:
>  > - 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
>  
>  Agreed.
>   
Definitely +1 as well.

>  > - (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).
>  
>  Agreed.
>  
>  CPython & pip use the "foo3.4, foo3" convention, so that seems enough of a
>  reason to use that convention by default. We may want a "unless upstream does
>  it differently" caveat though.
>   
Second caveat here is that currently we use version suffixes to denote
a command coming from a compat package.  If we make this change we need to
address that as well.  So, you might have sphinx-build, sphinx-build-2,
sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python
interpreter.  If you need a forwards or backwards compat package you might
also have an 0.9 and 1.1 that you need to tack on.  Possible solution here:
use a "v" prefix for the compat package's version.  So if the default
package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9
packages provide:

* sphinx-build-v0.9
* sphinx-build-2-v0.9
* sphinx-build-2.7-v0.9
* sphinx-build-3-v0.9
* sphinx-build-3.7-v0.9

Also an addition: It would be great for us to always have a "major version number
only" script name.  Currently there's a few packages (python3-nose, I'm
looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4.
That means scripts (user scripts as well as spec files) have to change
whenever we update python3 to a new major release.  Having the major only
form for all of these binaries will alleviate that.  Packagers can just
create a symlink if upstrean doesn't provide the -MAJOR version.

>  > - As for binaries/scripts in /usr/bin (assuming there are both
> python2 and
>  python3 versions), the unversioned files should point to python2 version. This
>  aligns with /usr/bin/python still pointing to python2.
>  
>  This also aligns with CPython & pip conventions. Between them, only
> "pyvenv"
>  runs under Python 3 by default, and that's only because it doesn't exist in
>  Python 2.
>   
One exception to this, I think, should be 2to3.  Or perhaps python-tools
should stop shipping 2to3 and the other /bin/ scripts which python3-tools
ships and are not needed in two versions (Not sure if any of those scripts
actually need to be carried in two versions.. pygettext.py might need to be
tested to be sure the python3 version can handle all sorts of python2
strings correctly).

-Toshio