clarification: python2 modules allowed to go into python2-foo?

[Thomas Spura]

Hi,

currently we are discussing, if it makes more sense to provide a
python-ipython package or a python2-ipython package, because we are
restructuring the package structure of ipython anyway right now [1].
The current python guidelines [2] don't mention, if new python2
providing modules still must/may/should be in a python-foo package, or
if it would be better to put them directly into an python2-foo
package.

Reasoning for python2-foo:
When /usr/bin/python will provide python3, this means, that the normal
python-foo MUST be build with python3 as python needs to refer to the
current default /usr/bin/python --version.

Reasoning for python-foo:
The majority of modules providing python modules have a python-foo
structure. So when switching to /usr/bin/python = python3, it would
also make sense to ONLY do that with the main python package, but all
python-foo package still provide python2 modules and when you want to
have python3 modules, you MUST require python3-foo. The drawback is,
that you cannot rely on "The package which is named python-foo will be
build with the default python interpreter."

I'd vote for python2-foo for new packages and renaming the old
python-foo packages unless they build for $current supported python
versions (atm: python2 AND python3) at the same time (and python3-foo
for python3 modules etc). That pythonX-foo package, where X is the
first digit of the default python interpreter MUST provide python-foo.
This will allow us to be ready for
python3,python4,python5,python4711...

What is your opinion towards this?

Greetings,
     Tom

P.S.: For the case of ipython, we can still leave it at ipython
without any pythonX- in front of it to avoid this, but it would be
great to have a general guidelines for this and I'm happy to help
renaming old packages/move forward to python4711.

[1] http://fedoraproject.org/wiki/Features/IPython_0.13
[2] http://fedoraproject.org/wiki/Packaging:Python

[Toshio Kuratomi]

On Wed, Jul 18, 2012 at 11:04:02AM +0200, Thomas Spura wrote:
>  Hi,
>  
>  currently we are discussing, if it makes more sense to provide a
>  python-ipython package or a python2-ipython package, because we are
>  restructuring the package structure of ipython anyway right now [1].
>  The current python guidelines [2] don't mention, if new python2
>  providing modules still must/may/should be in a python-foo package, or
>  if it would be better to put them directly into an python2-foo
>  package.
>   
See:

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_....

and also the first sentence of the python3 module naming section.

"An rpm with a python prefix or suffix means a python2 rpm so we need
a different prefix to denote python3 packages."


>  Reasoning for python2-foo:
>  When /usr/bin/python will provide python3, 
It's unclear to me that this is in the cards.  It's certainly not going to
happen in the next year.  I'd bet that it won't even happen in the next two
years.  There's several pieces that can be used to help with that decision:

Case 1)
* Most tools switch over to using python3 by default
* We get to the point where python3 is installed on all standard Fedora installs
* We get to the point where python(2) is not installed on standard installs.

Case 2)
* PEP 394 http://www.python.org/dev/peps/pep-0394/ is updated to recommend
  that /usr/bin/python points to /usr/bin/python3
* Fedora follows suit
* Some of the criteria in Case 1 has also been satisfied

Case 3)
* We reach 2015 and upstream python announces that there will be no further
  releases of python2
* We *have not* switched python2 code to a different interpreter that
  targets python2

>  this means, that the normal
>  python-foo MUST be build with python3 as python needs to refer to the
>  current default /usr/bin/python --version. 
This is not a given.  Right now, the python- prefix is defined as applying
to python2.  Full stop.  I think if we were to switch to /usr/bin/python ==
python3 for Fedora 18, then we'd continue to define python-foo as being for
python2.  The reason is that python3 has not become "python" in people's
minds yet.  People will still yum install python (rather than the python2
virtual provide) and continue to look for python-foo packages.

>  Reasoning for python-foo:
>  The majority of modules providing python modules have a python-foo
>  structure. So when switching to /usr/bin/python = python3, it would
>  also make sense to ONLY do that with the main python package, but all
>  python-foo package still provide python2 modules and when you want to
>  have python3 modules, you MUST require python3-foo. The drawback is,
>  that you cannot rely on "The package which is named python-foo will be
>  build with the default python interpreter."
>   
That is not a given now.  I don't think I really like the idea of it in the
future either.  If we're going to rename python-foo to python2-foo at some
point in the future, I'd rather we leave python3-foo as python3-foo.  Do not
create python-foo Virtual Provides or packages as that just leads to user
confusion at any transition points.

>  I'd vote for python2-foo for new packages and renaming the old
>  python-foo packages unless they build for $current supported python
>  versions (atm: python2 AND python3) at the same time (and python3-foo
>  for python3 modules etc). 
Splitting the package names so that some are python2-foo and some are
python-foo is a bad idea.

* User confusion -- I want to report a bug against "import foo".  Do I find
  that in bugzillla as python2-foo or python-foo?
* Any package which ships modules needs to install into different
  directories for python2 vs python3 so it needs to have two
  separate subpackages (whether or not the actual code would run on either)
* Any package which does not ship modules does not need python in the name:
  applications like gramps are just "gramps", not python-gramps.

So if we decide to rename the python-* modules to python2-* we should have
a flag day or series of flag days.  For instance,

* Fedora 27: All python-* modules are renamed to python2-* with Virtual
  Provides of python-*
* Fedora 35: All python2-* modules drop their python-* Virtual Provides

>   That pythonX-foo package, where X is the
>  first digit of the default python interpreter MUST provide python-foo.
>  This will allow us to be ready for
>  python3,python4,python5,python4711...
>   
As said above, I'm not for tying an actual name or a virtual provide to the
default python interpreter.  I'm also not generally for Provides: python-foo
meaning the value of /usr/bin/python OR the value of yum install python OR
the value of what python version gets installed exclusively if you do
a standard Fedora install.

I would be for renaming all python-* to python2-* at some appropriate time
in the future as a flag day with Virtual Provides of python-foo for
backwards compat at that time.  We could have a second flag day at some
point after that to remore (and not replace) the Virtual Provides.

>  What is your opinion towards this?
>  
>  Greetings,
>       Tom
>  
>  P.S.: For the case of ipython, we can still leave it at ipython
>  without any pythonX- in front of it to avoid this, but it would be
>  great to have a general guidelines for this and I'm happy to help
>  renaming old packages/move forward to python4711.
>   
Just a note (for others who might not be as familiar with where the lines
are drawn): I think the deepest we'd want to go in Fedora is one major
number.  python2, python3, python4.  This is because we port modules forward
to the most recent python version (what we ship in the python/python3
package) within that category.  If we had to ship a python3.3-3.3.1 package
for backwards compat for some singular modules, I think we'd want to
consider those as a special case and treat them along the lines of the EPEL
python27 packages (rather than name all of our package python27-foo,
python33-foo).  With current upstream versioning standards, we'd never ship
python271-foo packages.  The micro level versions are supposed to remain
compatible within the series.

-Toshio

[John Dennis]

I agree with what Toshio has said. We're wedded to the existing naming 
for a host of reasons.

As for the flag day Toshio postulates when we pull a lever and switch 
from python2 to python3, this is something that keeps me awake at night 
sadly. I know many of the python packages I'm involved with will simply 
not work with a python3 interpreter without a significant porting effort 
(then there is the issue of backward support for python2 in those same 
packages). This is especially relevant to Python modules written in C 
(e.g. CPython) of which there are quite a few.

So far the only relief from this dilemma has been the observation that 
we've been postponing the day of reckoning because the pain threshold is 
so high. In other words I don't have to deal with it today.

All of this is to reinforce the point that anything which might cause 
via whatever means python2 code to mistakenly execute in a python3 
environment would be disastrous and must be carefully avoided.

-- 
John Dennis <jdennis(a)redhat.com&gt;

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/