#271 Python naming change proposal
Closed: Fixed None Opened 11 years ago by bkabrda.

Hi,
as a result of discussion on packaging list [1], I'd like to propose a change in Python naming guidelines.
The current guidelines say that "If the upstream source has "py" (or "Py") in its name, you can use that name for the package." [2]. Since there is "can" in the sentence, some people use this scheme and others prepend "python-" before the package name. To make things more consistent, I propose deleting this sentence, so that all the packages must be named "python-${name}" no matter what "${name}" exactly is, except when the name already starts or ends with "python-", resp. "-python".
Moreover, I would like to propose generalization of this naming scheme to other Python interpreters, like Jython or Pypy. Packages for them should replace the "python" in package name in the above example by their name, e.g. "jython-${name}" and "pypy-${name}".
(There is yet another question - what the general guidelines for building packages for other Python interpreters should be, which should probably be discussed, but is out of scope of this ticket...)

Thank you!

[1] http://lists.fedoraproject.org/pipermail/packaging/2013-March/008977.html
[2] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29


First part, dropping the "py prefix" exception: This proposal has come up before and failed to be be accepted. But we have a lot of new FPC members since the last vote on it. +1 from me.

Second part about other python interpreters: I would like to defer this as part of guidelines for how to package modules for those interpreters. Not sure if we should follow the ruby lead and package the .py files for those as generic packages for all mostly-compatible interpreters. Since we should not be building jython or pypy modules without those guidelines, deferring what to name them doesn't seem like a burden. -1 from me.

Complete agreement with Toshio here. I have long disliked the "py" exception, so definite +1 on removing it from me. I also see no point in trying to name packages for alternate Python interpreters at this point, though of course work on guidelines for those needs to move ahead.

(+1:8, 0:0, -1:0) Drop the "py" naming exception, require the use of "python-" prefix.

Existing packages which used the naming exception may rename themselves using the normal method (rename review), but are not required to do so, they are considered "grandfathered". Alternately, if someone wished to ask FESCo for approval to do a mass rename of packages in this category at a specific point in a development cycle, they should feel free to do so.

The other proposal (interpreter specific naming) was rejected. The FPC would be willing to consider naming for additional interpreters as part of interpreter specific guidelines, however, since these interpreters have full compatibility with python code as a goal, it should not be necessary.

Hi, removing the "py" naming exception was accepted, the guidelines however still contain it. Could you please modify the guidelines accordingly? Thanks.

Done. Thanks for the reminder. Announcement text:

'''

The Naming Guidelines for python modules has been updated to remove the exception for packages which have a "py" prefix in the upstream name. This change comes at a time when python2 and python3 modules are commonly built from the same package and all python3 modules are required to have a "python3" in their name. This change makes it easier for users to identify that the python3-foo module is part of the python-foo package for filing bugs and searching for the python3 version of a package they use in python2.

Note that packages that are already in Fedora with names allowed under the old guidelines are considered grandfathered. Renaming makes sense but the FPC is not requiring that they do. This is up to the individual package maintainers (or FESCo should someone ask them for permission to do a mass package rename).

'''

Metadata Update from @toshio:
- Issue assigned to spot

7 years ago

Log in to comment on this ticket.

Metadata