#526 Mandatory python3 packaging when upstream supports python3
Closed: Fixed None Opened 4 years ago by tibbs.

I was surprised to find we have no rule which mandates the creation of python3-* packages when upstream supports python3. Since I do all of my work in python3 now, I keep running into this. So, in the event that my brain is still functioning and we actually lack such a rule, I think we should add one. After all, there's not much point in making python3 "the default" if there's no requirements that python3-supporting packages actually be packaged for python3.

I am working on a separate cleanup of the python guidelines, but here's a simple proposal.

Add a new section "Python version support" at the very beginning of the guideline containing the following paragraph:

In Fedora we have multiple python runtimes, one for each supported major release. At this point that's one for python2.x and one for python3.x. If a piece of software supports python3, it must be packaged for python3. If it supports python2 as well, it may be packaged for python2. If it supports only python2 then it must not be packaged for python3.

Then delete the first sentence of the "multiple python runtimes" section, and the the warning at the beginning of the "subpackages" section.


Historical note: The rationale for not including it was that we don't demand that users package or target the latest version things. If there's an older stack that they're willing to package and support in Fedora then they are welcome to only package for that. A more concrete issue I wanted to address was avoiding the case where a maintainer is capable of finding and fixing problems in the pyhton2 package because that's what they use but unable to do the same for the python3 portion because they only added that to satisfy guidelines.

With that historical note made, it may be that we want to push people into python3 (As you point out the Python3 by default Feature being a statement of intent for the distribution) and so I don't have an objection to the guidelines being updated in this way. Just want to make sure you understand why it is that way to properly evaluate the consequences of changing it.

The new justification would probably be along the lines of: "In Fedora we strive to move the state of the art forward rather than holding it back. When a new gcc comes out we do work to port existing packages to the newer version rather than staying on the old version until all problems are fixed. The jump from python2 to python3 is somewhat bigger than that but we believe that this baby step is reasonable for this stage of python3's acceptance. It makes sure that people who can use either python2 or python3 have the option to code in python3 if the upstreams of their libraries support it while not forcing Fedora packagers to port the code to python3 if the upstream has not."

I'm not entirely sure I understand some of that rationale, to be honest. Of course we don't absolutely require that people package the latest version of any specific piece of software. Obviously we have the whole 'First' thing, indeed, but we do value stability. But this isn't about packaging the latest version; nobody is saying that packagers must update to a newer version just to get python3 compatibility. But if the version they're packaging does support py3 then they should certainly provide a py3 package.

I suppose the proposal could more specifically state "if the version of the software you package supports py3 then you must provide a py3 package" so nobody will infer that they must update the software just to get py3.

Honestly I don't understand why anyone wouldn't just do the py3 package. Does it have something to do with EPEL? Are the guidelines too complicated?

Replying to [comment:2 tibbs]:

Honestly I don't understand why anyone wouldn't just do the py3 package. Does it have something to do with EPEL? Are the guidelines too complicated?

I guess there are simply too many guys out there who don't give a damn about Python 3 and it's certainly possible there are some among the Fedora packagers as well. For example if someone only packages the Python module to satisfy a dependency of something else they need (that thing running on Python 2).

+1 for the guideline change

I wonder if python3 packaging couldn't be made a bit more "automatic". I've been thinking about how to do it (and there are a couple of other open FPC tickets about it) but I haven't really had much time to get into it. In any case, when I have a chance to get around to that again I'll be sure to bring it up on the python-devel list.

I kind of also wonder if we should start thinking about naming the python2 packages with "python2-" instead of "python-", but again, that's a separate issue.

I think we should rename the packages, if the python2 packages build for python2 only. It would still be nice to have unversioned python packages, which means, that it is built with the systems default python. To ease the transition, I wanted to add some kind of '''%python_provide''' [https://fedoraproject.org/wiki/Changes/Python_3_as_Default#Scope macro].

Robert prefered to do this transition in a two step fashion. So first switch the default python and do the renaming a release later. [https://lists.fedoraproject.org/pipermail/python-devel/2015-April/000693.html Here] is the starting thread about python3 as default.

@tibbs: Yeah, I used several tangential examples. Here's a more direct example: If someone packages a C library that has bindings for python2, python3, ruby, and perl we don't mandate that packagers have to package all (or even any) of the bindings. Again, this is just history... I'm okay with deciding that the push to python3 prioritizes a different rationale.

For the renaming -- I've gone on record on the mailing list about which ideas around that I think are good and which ideas I think are horrible about that idea. We should probably continue that discussion in a different forum so as not to pollute this ticket.

I've created repository with packaging guildelines at github.com/fedora-python

https://github.com/fedora-python/packaging-guidelines/

You can see some changes made by myself:

https://github.com/fedora-python/packaging-guidelines/commit/06323a740d24509dc15d51cec3771f3bbdfa40bc

I would like you all interested in shaping python packaging guidelines to move there and open issues or send PRs to discuss any changes you think are necessary (regarding the python3 as default).

I'm +1 for requiring python3 if available

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/teams/fpc/fpc.2015-05-14-16.01.txt):

  • 526 Mandatory python3 packaging when upstream supports python3


    (geppetto, 16:58:57)
  • ACTION: Mandatory python3 packaging when upstream supports python3
    (+1:5, 0:0, -1:0) (geppetto, 16:59:54)

Announcement text:

It is now mandatory that modules which support python3 be packaged for python3. Python modules which support both python2 and python3 may be packages for both, or just python3. Packaging of modules which support only python2 are unaffected.
* https://fedoraproject.org/wiki/Packaging:Python
* https://fedoraproject.org/w/index.php?title=Packaging%3APython&diff=413621&oldid=409012
* https://fedorahosted.org/fpc/ticket/526

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata