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
--
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
