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

[Bohuslav Kabrda]

----- Original Message -----
> On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
> > 
> > On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda at redhat.com> wrote:
> > > - (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

I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at the very end in every case is better. In other words, the binary would normally be "sphinx-build-0.9" and we just append "-3.4" to it.
Also, this makes me realize more arguments to append Python version with dash, not without it:
1) sphinx-build-v0.93.4 would be very confusing (I do understand that this is a downstream problem, but see the following point)
2) Similarly, if there is an upstream whose entry_point/script ends with a number (pep8 for example), it'd be highly confusing to use the notation without dash, it would yield pep83.4 assuming the upstream community would accept this scheme. This feels just wrong.

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

I do agree that we should have that, although you can now use nosetests-%{python3_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).

Agreed, it's been on my todolist for quite some time to make 2to3 from python3-tools *the* 2to3.

> -Toshio

-- 
Regards,
Slavek Kabrda