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)
