----- Original Message -----
> On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
> >
> > On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda@xxxxxxxxxx> 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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
