Re: Use Python3 where possible
Hi Matthias,
Thanks for bringing this topic.
On 03/15/2016 11:20 AM, Matthias Klose wrote:
> The recent update of pep8 to use Python3 by default, and the regressions
> mentioned in #807409 reminded me, that we probably should address the
> use of Python3 more pro-actively.
>
> The pep8 binary package included the Python2 modules, plus the scripts,
> the python3-pep8 package only included the Python3 modules. The recent
> upload added a python-pep8 package, and let the pep8 package depend on
> python3-pep8, breaking packages which use the module, but not the binary
> package. I still think this way forward is the correct way to go (maybe
> adding some Breaks if these are known in advance).
>
> There are probably more packages like these, which should be converted
> this way. Maybe a popular candidate is sphinx, where almost always
> python-sphinx is used as a b-d instead of python3-sphinx.
Probably that's because it "only" generates static docs, and we don't
really care enough how they are generated. If sphinx-build was to become
Python 3 only through deprecation, then maybe we'd start migrating more
aggressively.
> I would like to come up with a recommendation that if a python module
> ships scripts, Python3 is used for these scripts, and the Python2
> version of these scripts should be dropped (and python -m ...) should be
> used instead. An alternative might be to use separate names for the
> scripts (e.g. ending with 2, or like in pillow one set without a suffix
> (for Python3), and one set with a .py suffix (Python2)). The most
> conforming name for the scripts should always use Python3.
>
> Having a lintian warning that a package still uses Python2 instead of
> Python3 might help as well, however maybe it should start as an
> "information" instead of a warning.
>
> Matthias
What I'm fearing here is repeating the same mistake done with 2to3: that
we want a one time migration, instead of a smooth transition where both
are co-existing. Maybe a longer co-existance will make it less painful.
That's more the path which I'm trying to take, until all can be
definitively switched at once to Python 3: this will be the point where
I'll start removing Python 2 support, but unfortunately I don't think
we're there just yet. I'm doing as much as I can to get there though.
What I've been doing everywhere, is providing /usr/bin/python2-foo and
/usr/bin/python3-foo, then using update-alternatives to provide
/usr/bin/foo. So far, I'm setting priorities to the Python 2
implementation, until most of OpenStack is ready for Python 3 (which I
believe could happen next year, as the functional testing will start
using Python 3).
I wrote a script within openstack-pkg-tools (BTW, it should be renamed,
as this helper package is generic and not really specific to OpenStack)
to write this fast: pkgos-alternative-bin, which you use this way:
pkgos-alternative-bin foo x y z
when foo is the name of the binary package (as in: python-foo), and x y
and z are the names of the programs in /usr/bin. pkgos-alternative-bin
creates the .postinst, .postrm and .prerm for you (take care, it may
ovewrite the one you already have), and propose the mv commands to add
in debian/rules.
This proves to be *very* efficient to work with: it takes less than a
minute to implement the update-alternatives stuff in a package if you're
using pkgos-alternative-bin to automate the process.
Now, probably I should implement a new parameter to select if one wants
Python 2 or Python 3 as the default implementation, to set
update-alternatives priorities accordingly. A (trivial) contribution for
doing this would welcome.
I hope this helps, comments welcome,
Cheers,
Thomas Goirand (zigo)
Reply to: