Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better. Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell? Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them. Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from? Why do we need it if Python 3 version is clearly named "python3-pygtk"?
So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3"). Another python implementations may pose a problem here - if we decide to package something for pypy, how do we call it? My suggestion would be to use it instead of "python-" - so "python-foo" would translate to "pypy-foo" in terms of binary RPM names. Please note, that very similar proposal was already discussed some time ago on python-devel [3], and this feature [4] (never actually proposed) was created back then. I'm trying to restart the discussion to make this moving.
Thoughts? Thanks.
On Thu, 28 Mar 2013 05:47:37 -0400 (EDT), Bohuslav Kabrda wrote:
Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better. Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell?
"yum search pygments" or the equivalent in a graphical package tool. Also "yum list py*|grep pygments" (or grep -i …) would find it.
Trial-and-error guessing of package names isn't practical. Searching manually in possibly alphabetically sorted lists of thousands of packages isn't practical either.
The uppercase "Py" is a good example. In bugzilla, uppercase package names are listed before lowercase package names. Nasty. A "yum search" and "yum list py*" is case-insensitive, however.
Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them.
When and how to apply such prefixes has confused packagers/reviewers before:
# yum list django*|grep ^django|wc -l 5 # yum list python-django*|grep ^python-django|wc -l 70
Some of the django-* packages have been renamed, but this shows that guessing prefixes wouldn't work well either.
Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from?
The naming is derived from the GTK+ framework base packages: gtk+ (v1.x), gtk2 (v2.x), gtk3 (v3.x).
Why do we need it if Python 3 version is clearly named "python3-pygtk"?
?
So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3").
Do you propose it just because of the package searching and installation attempts you've described? What other benefits would there be? Currently, all Python packages should start with "py" (or "Py"), except if it's a package that doesn't extend Python but some program (e.g. claws-mail-plugins-python).
----- Original Message -----
On Thu, 28 Mar 2013 05:47:37 -0400 (EDT), Bohuslav Kabrda wrote:
Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better. Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell?
"yum search pygments" or the equivalent in a graphical package tool. Also "yum list py*|grep pygments" (or grep -i …) would find it.
Trial-and-error guessing of package names isn't practical. Searching manually in possibly alphabetically sorted lists of thousands of packages isn't practical either.
The uppercase "Py" is a good example. In bugzilla, uppercase package names are listed before lowercase package names. Nasty. A "yum search" and "yum list py*" is case-insensitive, however.
Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them.
When and how to apply such prefixes has confused packagers/reviewers before:
# yum list django*|grep ^django|wc -l 5 # yum list python-django*|grep ^python-django|wc -l 70
Some of the django-* packages have been renamed, but this shows that guessing prefixes wouldn't work well either.
That's exactly why I'm proposing a clear and "non-specialcased" approach.
Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from?
The naming is derived from the GTK+ framework base packages: gtk+ (v1.x), gtk2 (v2.x), gtk3 (v3.x).
So why isn't the python 3 package named python3-pygtk2, but just python3-pygtk?
Why do we need it if Python 3 version is clearly named "python3-pygtk"?
?
So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3").
Do you propose it just because of the package searching and installation attempts you've described? What other benefits would there be? Currently, all Python packages should start with "py" (or "Py"), except if it's a package that doesn't extend Python but some program (e.g. claws-mail-plugins-python).
I don't think that this is "just because". The fact that you have to workaround these by guessing the package names or doing searches prior to installation proves that something is wrong/inconsistent. If you look at naming guidelines for other languages that prepend something Fedora-specific before the actual package name (Ruby, Perl, PHP, ...), you'll see that all of them have completely clear naming scheme. Also, try to look at some other distro naming rules for Python - e.g. Mageia [1], OpenSuse [2], Debian [3] all name python extension modules python-foo, resp. python3-foo.
-- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc4.git0.1.fc19.x86_64 loadavg: 0.02 0.03 0.11 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Thu, 28 Mar 2013 07:47:37 -0400 (EDT), Bohuslav Kabrda wrote:
Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from?
The naming is derived from the GTK+ framework base packages: gtk+ (v1.x), gtk2 (v2.x), gtk3 (v3.x).
So why isn't the python 3 package named python3-pygtk2, but just python3-pygtk?
Cannot find the package in Rawhide or F19, so I cannot examine its contents. It could be that it can use either GTK with introspection or includes pygtkcompat or whatever.
The fact that you have to workaround these by guessing the package names or doing searches prior to installation proves that something is wrong/inconsistent.
Deviating from upstream release names bears risks, too.
Given your example of "pygtk", currently one would need to find out that it's called "pygtk2", and in the future one could not install it as "pygtk" because it would be renamed to "python-pygtk" just for consistency.
If you look at naming guidelines for other languages that prepend something Fedora-specific before the actual package name (Ruby, Perl, PHP, ...), you'll see that all of them have completely clear naming scheme.
Can't verify that easily. There are packages "foo-php", and there even is a package "foo-php-devel" (and due to that it gets multilib'ed).
Also, try to look at some other distro naming rules for Python - e.g. Mageia [1], OpenSuse [2], Debian [3] all name python extension modules python-foo, resp. python3-foo.
Some other dists also apply different naming schemes for shared library packages. Even others dists create different sets of subpackages.
Wait for somebody else's comments. ;) I'm not opposed to changing the guidelines, I just think it would not matter much, and I don't yet see that it would resolve all confusion (such as the python-foo vs. foo-python naming cases). IMO, we better improve %summary and %description, so searching for packages will become much more usable.
On Thu, Mar 28, 2013 at 12:20 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 28 Mar 2013 05:47:37 -0400 (EDT), Bohuslav Kabrda wrote:
Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better.
Thanks for this follow-up! The feature page, I created, is somehow stalled, because it seems the added complexity of python naming didn't qualify to improve the current "it's working fine as it is now - just search where the package you are looking for is packaged" situation... Count me in for creating a new python packaging naming guideline.
Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell?
"yum search pygments" or the equivalent in a graphical package tool. Also "yum list py*|grep pygments" (or grep -i …) would find it.
Trial-and-error guessing of package names isn't practical. Searching manually in possibly alphabetically sorted lists of thousands of packages isn't practical either.
"Isn't practical" is a perfect reason to improve it with a new python package naming proposal.
The uppercase "Py" is a good example. In bugzilla, uppercase package names are listed before lowercase package names. Nasty. A "yum search" and "yum list py*" is case-insensitive, however.
Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them.
When and how to apply such prefixes has confused packagers/reviewers before:
# yum list django*|grep ^django|wc -l 5 # yum list python-django*|grep ^python-django|wc -l 70
Some of the django-* packages have been renamed, but this shows that guessing prefixes wouldn't work well either.
I'd consider this as the same problem like above. It's simply inconsistent and a python prefix as a must-have would be one/the solution.
So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3").
Do you propose it just because of the package searching and installation attempts you've described? What other benefits would there be? Currently, all Python packages should start with "py" (or "Py"), except if it's a package that doesn't extend Python but some program (e.g. claws-mail-plugins-python).
I'd further prefer to have an dependent naming from the underlying interpreter in the python package name e.g. python2-foo and python3-foo while python-foo must contain the module foo, that is build with the current default interpreter. That can be archived, when adding some %{python_provide}-like macros, that decides in all python*-foo packages, which one now provides the python-foo virtual provides, but further complicates the python packaging to some extend...
That's why I want to further propose: - A module must contain the name of the underlying python interpreter, e.g. python3-foo, sssd-python3. - A macro will be created, that decides on build time, if the corresponding package provides the python-foo or sssd-python package with the default interpreter. such as %python_provides $name $interpreter, e.g. %python_provides sssd-python python3
Drawback: - There is no possibility to add a python-foo package, that provides the "foo" package, built with the current default interpreter. Maybe we should add an exception for that? I'd prefer to forbid the python-foo naming completely...
Why to be independent of the python interpreter? This will create some (not to say much) work to set this new guidelines in place, but it will pay out in the long term, when further python interpreter migrations might happen.
Comments? Thoughts?
Greetings, Tom
On Thu, 28 Mar 2013 13:43:16 +0100, Thomas Spura wrote:
Trial-and-error guessing of package names isn't practical. Searching manually in possibly alphabetically sorted lists of thousands of packages isn't practical either.
"Isn't practical" is a perfect reason to improve it with a new python package naming proposal.
Check out the other replies. It would be much more of a reason to be as close as possible to upstream names, so documentation on the web would work, too, and users would get some result without guessing package names. Although I think running package searches is superior.
http://www.pygtk.org/ | | PyGTK for Linux | | PyGTK is included in most Linux distributions (including Debian, Fedora, | Ubuntu, Opensuse, Gentoo, Mandrake, Redhat, SUSE...);
Yet "yum install PyGTK" would not work. Introducing lots of prefixes or interpreter version identifiers is unlikely to end up with a clean/clear solution.
$ rpm -qR soundconverter|grep py /usr/bin/python gnome-python2-bonobo gnome-python2-canvas gnome-python2-gconf gnome-python2-gnome gnome-python2-gnomevfs gstreamer-python notify-python pygtk2
On Thu, Mar 28, 2013 at 2:00 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 28 Mar 2013 13:43:16 +0100, Thomas Spura wrote:
Trial-and-error guessing of package names isn't practical. Searching manually in possibly alphabetically sorted lists of thousands of packages isn't practical either.
"Isn't practical" is a perfect reason to improve it with a new python package naming proposal.
Check out the other replies. It would be much more of a reason to be as close as possible to upstream names, so documentation on the web would work, too, and users would get some result without guessing package names. Although I think running package searches is superior.
http://www.pygtk.org/ | | PyGTK for Linux | | PyGTK is included in most Linux distributions (including Debian, Fedora, | Ubuntu, Opensuse, Gentoo, Mandrake, Redhat, SUSE...);
Yet "yum install PyGTK" would not work. Introducing lots of prefixes or interpreter version identifiers is unlikely to end up with a clean/clear solution.
%python_provides PyGTK $interpreter would help here, which provides the PyGTK package from the correct $interpreter-pygtk package. This way, you know for sure, where to search for in bugzilla, such as python2-pygtk (or python2-PyGTK) and the yum install command would work as expected from the web. I do consider this a "clean solution".
Greetings, Tom
On Thu, 28 Mar 2013 14:09:41 +0100, Thomas Spura wrote:
%python_provides PyGTK $interpreter would help here, which provides the PyGTK package from the correct $interpreter-pygtk package. This way, you know for sure, where to search for in bugzilla, such as python2-pygtk (or python2-PyGTK)
Bugzilla "component" names are the src.rpm %{name}s. You would first need to change that, so a pygtk2.src.rpm is not added to Bugzilla as "pygtk2" but with the names of (all?) its binary rpm(s) it builds.
On Thu, Mar 28, 2013 at 2:18 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Thu, 28 Mar 2013 14:09:41 +0100, Thomas Spura wrote:
%python_provides PyGTK $interpreter would help here, which provides the PyGTK package from the correct $interpreter-pygtk package. This way, you know for sure, where to search for in bugzilla, such as python2-pygtk (or python2-PyGTK)
Bugzilla "component" names are the src.rpm %{name}s. You would first need to change that, so a pygtk2.src.rpm is not added to Bugzilla as "pygtk2" but with the names of (all?) its binary rpm(s) it builds.
What I meant is, that we have e.g.: python2-pygtk.src.rpm python3-pygtk.src.rpm pypy-pygtk.src.rpm
each of them have this line in the spec files respectively: %python_provides PyGTK python2 %python_provides PyGTK python3 %python_provides PyGTK pypy
and only the python2-pygtk package emits the PyGTK provides, and the others don't. This way, "yum install PyGTK" still works, but you still need to know, that it was built from the $default_interpreter-pygtk package as there won't be a pygtk2 component in bugzilla.
I think, this is less confusing, than always searching for the correct src.rpm name for any python bug you want to file. What do you think?
Greetings, Tom
On Thu, 28 Mar 2013 14:47:46 +0100, Thomas Spura wrote:
Bugzilla "component" names are the src.rpm %{name}s. You would first need to change that, so a pygtk2.src.rpm is not added to Bugzilla as "pygtk2" but with the names of (all?) its binary rpm(s) it builds.
What I meant is, that we have e.g.: python2-pygtk.src.rpm python3-pygtk.src.rpm pypy-pygtk.src.rpm
Hard to comment on, because that's not what packages do so far. It's more normal that a single src.rpm (in Fedora package git) builds multiple packages from a single source tarball. If a previously Python 2 based project adds compatibility for Python 3, you would reuse the tarball and not start a new src.rpm with a different name. Here, building for a newer Python version would require a new src.rpm -- it's probably a better idea to create front-ends for bugzilla which know about the mapping from binary rpms to source rpms.
The low-level details about RPM macros and virtual provides don't interest me yet, btw.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/28/2013 05:47 AM, Bohuslav Kabrda wrote:
Hi all, so after spending some months with Python packaging, I came to think that the naming has to be standardized better. Problem 1: The naming guidelines say, that if there is "py" or "Py" in package name, you _can_ use that name for a package, otherwise use python-{name} [1]. So if I'm trying to install "pygments", I just try "pygments", but whoops - it's named python-pygments. How could I tell? Problem 2: If I install "PyYaml" (this time I was lucky and guessed correctly), then it's confusing that I have to install python3-PyYaml. Both should be prefixed "python[possibly 3]-", or none of them. Problem 3: The table in [2] is even more confusing. If the upstream name is "pygtk", why should Fedora's package be called "pygtk2"? Where did the "2" come from? Why do we need it if Python 3 version is clearly named "python3-pygtk"?
So my proposal would be: Let's make it mandatory for all the Python package names to be prefixed with python-/python3-. If the upstream name already starts with "python-", then let's use that (possibly inserting the "3"). Another python implementations may pose a problem here - if we decide to package something for pypy, how do we call it? My suggestion would be to use it instead of "python-" - so "python-foo" would translate to "pypy-foo" in terms of binary RPM names. Please note, that very similar proposal was already discussed some time ago on python-devel [3], and this feature [4] (never actually proposed) was created back then. I'm trying to restart the discussion to make this moving.
Thoughts? Thanks.
I have a related question, actually. We're splitting a package out of the main 'sssd' package so that the pure-python config API lives in a noarch package instead of the main (arch-full) package.
The packaging guidelines are ambiguous about how we would have to name this subpackage. I suggested that we name it python-sssdconfig, but others are recommending naming it sssd-configapi and avoiding the python label entirely.
See https://lists.fedorahosted.org/pipermail/sssd-devel/2013-March/014181.html and follow-ups for a little more discussion.
On 03/28/2013 07:25 AM, Stephen Gallagher wrote:
I have a related question, actually. We're splitting a package out of the main 'sssd' package so that the pure-python config API lives in a noarch package instead of the main (arch-full) package.
If that "pure python config API" is a python module, then a python- prefix is the way to go.
Though... it may also help frame the answer if you could describe the purpose of making the subpkg in the first place?
-- rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/28/2013 08:32 AM, Rex Dieter wrote:
On 03/28/2013 07:25 AM, Stephen Gallagher wrote:
I have a related question, actually. We're splitting a package out of the main 'sssd' package so that the pure-python config API lives in a noarch package instead of the main (arch-full) package.
If that "pure python config API" is a python module, then a python- prefix is the way to go.
Though... it may also help frame the answer if you could describe the purpose of making the subpkg in the first place?
See https://fedorahosted.org/sssd/ticket/1839
- From my comments in the patch review thread: Rel-eng was complaining that we had python modules contained in an arch-specific package that were being put on disk in a noarch location. Rel-eng made the incorrect assumption that this meant that the modules were actually arch-specific, which they are not; SSSDConfig is pure-python and safely noarch.
The correct solution to this is for us to add a python-sssdconfig noarch subpackage and Requires: it from the 'sssd' package (for backwards compatibility).
Basically, it's generally considered incorrect for an arch-specific package to be putting files into %{python_sitelib}
On 03/28/2013 07:40 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/28/2013 08:32 AM, Rex Dieter wrote:
On 03/28/2013 07:25 AM, Stephen Gallagher wrote:
I have a related question, actually. We're splitting a package out of the main 'sssd' package so that the pure-python config API lives in a noarch package instead of the main (arch-full) package.
If that "pure python config API" is a python module, then a python- prefix is the way to go.
Though... it may also help frame the answer if you could describe the purpose of making the subpkg in the first place?
See https://fedorahosted.org/sssd/ticket/1839
- From my comments in the patch review thread: Rel-eng was complaining that we had python modules contained in an
arch-specific package that were being put on disk in a noarch location. Rel-eng made the incorrect assumption that this meant that the modules were actually arch-specific, which they are not; SSSDConfig is pure-python and safely noarch.
The correct solution to this is for us to add a python-sssdconfig noarch subpackage and Requires: it from the 'sssd' package (for backwards compatibility).
I'm not sure I would agree with the original assertion or this "correct solution" conclusion. At least, it's not supported by our packaging guidelines anywhere that I'm aware of. (or is it?)
-- rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/28/2013 08:47 AM, Rex Dieter wrote:
On 03/28/2013 07:40 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/28/2013 08:32 AM, Rex Dieter wrote:
On 03/28/2013 07:25 AM, Stephen Gallagher wrote:
I have a related question, actually. We're splitting a package out of the main 'sssd' package so that the pure-python config API lives in a noarch package instead of the main (arch-full) package.
If that "pure python config API" is a python module, then a python- prefix is the way to go.
Though... it may also help frame the answer if you could describe the purpose of making the subpkg in the first place?
See https://fedorahosted.org/sssd/ticket/1839
- From my comments in the patch review thread: Rel-eng was
complaining that we had python modules contained in an arch-specific package that were being put on disk in a noarch location. Rel-eng made the incorrect assumption that this meant that the modules were actually arch-specific, which they are not; SSSDConfig is pure-python and safely noarch.
The correct solution to this is for us to add a python-sssdconfig noarch subpackage and Requires: it from the 'sssd' package (for backwards compatibility).
I'm not sure I would agree with the original assertion or this "correct solution" conclusion. At least, it's not supported by our packaging guidelines anywhere that I'm aware of. (or is it?)
Well, I'm not sure it's specified in the guidelines anywhere, but I think it does make sense to have noarch components stored in a noarch package. Let's presume for the moment that splitting it out is acceptable and talk more about the naming. In this situation, does python-sssdconfig make the most sense as a subpackage name?
In essence, should we be treating all python packages as if they are subpackages of python implementing some other application's functionality, or should we be acting like MySQL (with their MySQL-Python) subpackage?
On Thu, Mar 28, 2013 at 09:09:15AM -0500, Rex Dieter wrote:
On 03/28/2013 08:31 AM, Stephen Gallagher wrote:
Let's presume for the moment that splitting it out is acceptable and talk more about the naming. In this situation, does python-sssdconfig make the most sense as a subpackage name?
yes, imo, +1
That would be my preference as well.
-Toshio
"BK" == Bohuslav Kabrda bkabrda@redhat.com writes:
BK> Let's make it mandatory for all the Python package names to be BK> prefixed with python-/python3-.
You won't get any argument from me; I've long thought that the "py" naming exception is bollocks and that python deserves no special treatment here. Do note, however, that even if we changed the guidelines, this would have no effect on existing packages because we wouldn't dream of requiring any sort of renaming.
- J<
On Thu, Mar 28, 2013 at 08:37:46AM -0500, Jason L Tibbitts III wrote:
"BK" == Bohuslav Kabrda bkabrda@redhat.com writes:
BK> Let's make it mandatory for all the Python package names to be BK> prefixed with python-/python3-.
You won't get any argument from me; I've long thought that the "py" naming exception is bollocks and that python deserves no special treatment here. Do note, however, that even if we changed the guidelines, this would have no effect on existing packages because we wouldn't dream of requiring any sort of renaming.
+1
-Toshio
packaging@lists.fedoraproject.org
-
Bohuslav Kabrda -
Jason L Tibbitts III -
Michael Schwendt -
Rex Dieter -
Stephen Gallagher -
Thomas Spura -
Toshio Kuratomi