On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkabrda(a)redhat.com> 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.
- (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.
- 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.
- Some time ago, I also put together a proposal for some larger
changes
in Python packaging [5], mostly in how the subpackages for different
interpreters should be done. I opened an FPC ticket [6] to get some
comments and it seemed that FPC was favorable. While I still think it'd be
great to do this change, it'll require a significant effort and that is
better spent helping upstreams to port to Python 3 ATM. So I'd also like to
receive more comments on this proposal, although I think we should postpone
it to F23 (or maybe even later).
I haven't reviewed this part yet.
Regards,
Nick.