Hello all,

I've been recently somewhat involved in openSUSE stuff, and I caught wind of a recent initiative to update their Python packaging.

Some background here: As some of you may know, for whatever unknown reason, openSUSE has historically had separate source packages and projects for Python 2 and Python 3 packages[1][2]. While this approach does make packaging more trivial in some regards, it has had the unfortunate consequence of making it so that the Python 2 and Python 3 packages of the same module often were wildly out of sync.

Last month, Jan Matejek (SUSE's Python stack maintainer, who is CC'd to this email) unveiled his "singlespec" project[3][4][5] and began transitioning Factory (their equivalent of Rawhide) to it. Factory has been undergoing the transition for the last month rather successfully.

Now, in Fedora (and Mageia), "single spec" is not new to us. We've been doing this for years. However, what is new is that openSUSE's packaging structure allows for dynamically generating "flavors" as subpackages to target Python 2, Python 3, PyPy, or whatever other implementation of Python you wish to support. For people familiar with openSUSE's Ruby packaging, this is not new, as it works the same way there.

I've taken a look at how the new openSUSE Python packaging works, and it appears to have shades of how Jason Tibbs' prototype Python packaging works[6]. I've not dug too deeply into Jason's work, but they do appear conceptually similar.

A deeper examination of the openSUSE packaging macros[7] reveals that it's designed to be mostly a superset of our macros in Fedora and Mageia. All the macros we currently use are defined in their macros, except for one: %python_provide. For the openSUSE macros, the "flavors" capability supersede the usage of %python_provide.

My main critique of the openSUSE packaging is that it enforces the usage of alternatives to select the "unversioned" binary. In my view, openSUSE uses alternatives too much across Python, Ruby, and other languages where they have multiple stacks supported. I'd much rather enforce a particular version of the binaries being unversioned (preferably the Python 3 version, unless there's some compelling reason otherwise) and have that always be used.

Another issue is that it depends on Python packages being reformatted to match the new convention. Unlike openSUSE, we have not been very good about pushing to restructure all of our Python packages to match our new preferred convention. That being said, we also have the advantage of having a Python dependency generator (though we are only using it for generating Provides at the moment, Mageia uses an earlier version of it to generate Provides and Requires, and openSUSE doesn't have this at all). If we were to incorporate their work, it could be modified to leverage our dependency generator so that this is less of a problem. We could fall back to the structured Python module package names when we're attempting to use modules that don't have the Provides (which are basically modules not built using setuptools or distutils).

However, I think that their work is complementary, and at least we could incorporate their macros into our standard set of Python macros. I would like to see us work with the openSUSE guys to see if we can come together on a unified standard of macros. I believe there's certainly a desire on both sides (especially with the OpenStack packaging teams, who'd like to not have to duplicate each other's work for their respective distributions).

What do you guys think?

Best regards, Neal

[1]: https://build.opensuse.org/project/show/devel:languages:python [2]: https://build.opensuse.org/project/show/devel:languages:python3 [3]: https://lists.opensuse.org/opensuse-packaging/2017-02/msg00105.html [4]: https://lists.opensuse.org/opensuse-packaging/2017-02/msg00107.html [5]: https://build.opensuse.org/project/show/devel:languages:python:singlespec [6]: https://pagure.io/python-macros [7]: https://github.com/openSUSE/python-rpm-macros