We need a separate ticket where we can keep track of all of the python changes that are flying around.

Currently I've sort of written up ticket:534, but that sort of expanded into multiple things. The proper implementation, where the %python_provide macro hides the details, will follow when the macros exist.

I have also removed the two initial admons and the note about mumpy/gtk at the end.

Other currently open python-related tickets:

ticket:542 - Forbidding -OO in py<3.5. Needs one vote.
ticket:281 - Has become sort of a catch-all for new python macros

Basically we're at the stage where various macros appear to have consensus among the python folks, and we just need to wait until they make it into the appropriate packages so that people can use them. It should be easy to drop them into redhat-rpm-macros and get that pushed out. I sincerely hope that it's possible to drop them into epel-rpm-macros as well and get rid of some of the EPEL-related boilerplate that so many packages carry.

The proposed macros as I understand them:

• %py_install - simplifies calling setup.py install.
• %pypi_name - This appears to only appear in the spec templates as a placeholder for the package name.
• %python_provides - Magically gets the various Provides: right.
• %py{2,3}_build - Handles calling setup.py build
• %py{2,3}_install - Handles calling setup.py install. Also creates lists for use in %files.

I'm looking at https://fedoraproject.org/w/index.php?title=User:Tomspur/Packaging:Python to see how these macros are used.

And since I'm looking at this, a couple of other macros come to mind:

• Two to replace python2-%{pypi_name} and python3-%{pypi_name} since these appear multiple times in the spec. (No suggestion on what they would be named.)
• %python2_provides and %python3_provides that don't need to be passed %python{2,3}-%{pypi_name}.
• Macros which encapsulate the pushd/popd pairs around %py{2,3}_{build,install}.

And a question. This note is present:

Instead of making two copies of the source tree, you can build for both python2 and python3 from one directory if the source already supports this.

How common is this? If it's common we may want to optimize for that case.