Jason Tibbitts suggested to open this ticket asap, there's no draft as of yet.
This is about https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages
So what we're really going to want to know is whether this is going to conflict with any existing practice. I don't think at this point we have any opportunity to give any input but on the surface everything seems pretty sane.
The only thing that really stands out is whether any of this will conflict or interact in some way with %python_provide. I don't think so, in the same way that the perl autodeps don't obviate the need for the perl MODULE_COMPAT thing, but it's good to be sure.
Do let us know when you have some sort of draft, even if it's early.
%python_provide and auto provides don't conflict. They're two different ways to specify a dependency, either by the upstream name or by the Fedora name.
The uses do overlap, but I think allowing packagers to stop using %python_provide in favor of auto provides is for a different discussion.
Here is a draft of the changes to the Fedora Packaging Guidelines for Python: https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python
There is a new section "Automatic Provides with a standardized name" [0] and also the expandable table for Macros [1] was updated.
[0] https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python#Automatic_Provides_with_a_standardized_name [1] https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python#Macros
The draft proposes creating 2 new macros, a draft of those can be found here: https://paste.fedoraproject.org/404739/
After a thorough discussion on the #fedora-python IRC channel with ignatenkobrain, pviktori and mhroncok, both the Guidelines draft and the macros will be amended.
Both the Guidelines and the macros were amended, here are the current versions.
Note that there will be a targeted rebuild of Python packages in rawhide this week to enable the functionality, therefore the guidelines should not be made available before that.
Current draft of the changes to the Fedora Packaging Guidelines for Python: https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python
[0] https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python#Automatic_Provides_with_a_standardized_name [1] https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/Python#Macros
The draft proposes creating 5 new macros, a draft of those can be found here: https://paste.fedoraproject.org/408829/27559514/
Somehow this ended up in the announce state and didn't get discussed at any meeting
Sadly trac workflow prevents me from moving it directly back from announce.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-08-25/fpc.2016-08-25-16.00.txt):
Hi,
The automatic Provides generator generates two Provides: python3dist(foo) and python3.5dist(foo). Perhaps that got people thiking that the proposed Requires macros also generate two requirements each, but that's not the case.
The Requires macros generate one Requires/BuildRequires each, but the generated requires are subtly different:
{{{ BuildRequires: python3dist(foo) Requires: python3.5dist(foo) }}}
Note that one has only the Python major version (3); the other one has major.minor (3.5).
It needs to be this way because: - If "python3.5dist(foo)" was used in BuildRequires, the SRPM would not be usable in Fedoras that have a different minor Python version (for example, "python3.6dist(foo)"). For these systems the SRPM would need to be re-generated from spec and sources.
Now, since the Requires and BuildRequires are so similar but subtly different, I fear that packagers would simply copy the "Requires: python3.5dist(foo)" line, and add "Build" in front of it, omitting the s/3.5/3/ change. Compare these lines:
{{{ %{python3_requires foo} %{python3_buildrequires foo} }}}
where there's only one, obvious change to go from one to the other.
The main reason for proposing the macros is to guard against that kind mistake.
A fuller write-up and discussion are at [0].
BTW, is there a good place to put guideline rationales? Writing all this in the guidelines themselves would make them quite long.
[0] https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/UZ5IZFW7AZVIU3XH6EX4262NVVJRJZUZ/
Here's something that wasn't mentioned enough before: These features are designed to support automated tools. It's still easy to use them in hand-written spec files, or review them, but when faced with a choice, we lean a bit more toward more toward robustness rather than simplicity and ease of use. So while the result still is meant to be easy to use, that isn't the only force behind the changes.
The draft could be written much more concisely if it only explained ''how'' to do things and ''what'' the macros do, and omitted the full rationale.
I think we are at the following impasse:
Packagers don't necessarily need to know details on ''why'', for example, we need to put X.Y in Requires but X in BuildRequires. (Except if they're curious.)
The FPC ''does'' need to know the rationale, so they can make an informed decision to approve.
Putting the full rationale in the Guidelines would make them long and confusing, especially for packagers. A shortened rationale (current draft) seems to confuse everyone. With no rationale, I fear we wouldn't have much chance of acceptance by the FPC.
I believe we should make a separate rationale page, and link it from the Guidelines to satisfy the FPC, guideline writers, and curious maintainers. This page would only have the rationale. Tips & tricks, best practices, anything of immediate use to package maintainers -- that's still for the Guidelines. [[BR]]This is not an attempt to move control away from the FPC -- we could have rationale go through a ratification process too, if needed. Rather, it's an attempt to simplify the guidelines for the reader. [[BR]]Does that sound like a good idea?
I don't see reason why not to switch to pythonXdist() for Requires as well. So far we don't support (and hopefully not planning) multiple python versions. Which means pythonXdist() will always point to correct module.
There is only one case where it can be useful, when we are rebuilding Python stack, so we will immediately see packages which are still not rebuilt (so dependency chain will be broken), but apparently it's possible to do this using repoquery.
I would like to avoid any new macroses and just propose to people use BR: pythonXdist(foo) and R: pythonXdist(foo).
We have came up with a middle-of-the-road proposal: - 2 main macros (%py2_dist, %py3_dist) - 1 secondary macro (%py_dist_name) just for converting dist names to canonical format; this macro will only be displayed in the click-to-expand table of macros in the Python guidelines
Usage examples: - BuildRequires: %{py2_dist PyMySQL} - Requires: %{py3_dist PyMySQL} - Requires: python3dist(%{py_dist_name PyMySQL})
BuildRequires: %{py2_dist PyMySQL}
Requires: %{py3_dist PyMySQL}
Requires: python3dist(%{py_dist_name PyMySQL})
Therefore from the original 5 macros we're down to 2-3.
'''This is the minimal set of macros that are needed to keep spec file compatibility between Fedora and EPEL.''' While Fedora can use just pythonXdist(..) tags in both BR and Requires, in EPEL we always have to use pythonX.Ydist(..), because EPEL has support for multiple Minor Python versions per each Major Python version (i.e. python34 and python35). ''Therefore, we need macros to keep this difference between Fedora and EPEL out of the spec files.''
pythonXdist(..)
pythonX.Ydist(..)
However, note that by using these 3 macros instead of the original 5 we will be forced to use X in both BR and R in Fedora, which will mean we'll lose the ability of detecting Python version incompatibility between modules at build time. This is very useful (especially for automated tools) when the Python stack is being rebuilt to a new Minor version, as ignatenkobrain noted above.
X
I still think the original proposal is better, but this one with just 3 macros would be OK.
Is there anything I can do to move this issue along?
Here are the relevant results of the last FPC meeting: https://meetbot.fedoraproject.org/teams/fpc/fpc.2017-01-05-17.00.log.html
I will update the ticket when the work is done.
Yeh, sorry, got busy and didn't update the ticket:
We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-01-05/fpc.2017-01-05-17.00.txt):
Here is the new Python packaging [guidelines draft], and here's a [diff] with the current guidelines.
[guidelines draft] https://fedoraproject.org/wiki/User:Torsava/PackagingDrafts/PythonProvides
[diff] https://fedoraproject.org/w/index.php?title=User%3ATorsava%2FPackagingDrafts%2FPythonProvides&diff=483701&oldid=483696
Macros were rewritten as well, the %pyX_dist macros now take multiple arguments: https://paste.fedoraproject.org/525585/
Should I set the status of the ticket to "meeting"?
There's been a slight correction, here's the new [guidelines diff].
[guidelines diff] https://fedoraproject.org/w/index.php?title=User%3ATorsava%2FPackagingDrafts%2FPythonProvides&diff=483708&oldid=483696
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2017-01-12/fpc.2017-01-12-17.01.txt):
Metadata Update from @churchyard: - Issue assigned to tibbs
Announcement text:
A section was added to the Python guidelines describing the automatic generation of Provides: which was added in Fedora 25. Descriptions of three new macros were also added.
Login to comment on this ticket.