Hi,
I wonder how python packages should be named as there are two conflicting naming conventions.
As an example I am using the case of the python library/program gogs-client, see the declined request [1]
First there are the generic naming guidelines which say that the dash '-' must not be used "as the delimiter for name parts".[2] However it is not very clear to be what name parts are in this context. Are "python" and "gogs-client" name parts or are "gogs" and "client" name parts?
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
I'd assumed that the more specific rule wins. However, do these two rules interfere in some way? Or have the rules been changed?
When looking at existing packages I get the impression that the policy for python packages is the active one (e.g. look at all the "python(2|3)?-python.*" packages).
Sebastian
[1]: https://build.opensuse.org/request/show/517141 [2]: https://en.opensuse.org/openSUSE:Package_naming_guidelines#Separators [3]: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy
hello,
On 18.8.2017 10:07, Sebastian wrote:
First there are the generic naming guidelines which say that the dash '-' must not be used "as the delimiter for name parts".[2]
ISTM you misread the part of the wiki, it says quite the opposite: you should use "-" (dash), you should NOT use other separators (such as "_", "+" and ".")
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
The issue with your request is the discrepancy in the package's PyPI identifier. Upstream seems to think the name should be "gogs_client", but uploaded as "gogs-client", except the filename is still "gogs_client".
Upstream sometimes does that, and PyPI does nothing to stop them. Such is the world we live in.
As I wrote on the request, "_" and "-" are treated the same by PyPI ecosystem. "pip install gogs-client" and "pip install gogs_client" are identical. So IMHO using "python-gogs-client" as the package name is equally correct as "python-gogs_client".
m.
On 08/18/2017 03:34 PM, jan matejek wrote:
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
The issue with your request is the discrepancy in the package's PyPI identifier. Upstream seems to think the name should be "gogs_client", but uploaded as "gogs-client", except the filename is still "gogs_client".
Upstream sometimes does that, and PyPI does nothing to stop them. Such is the world we live in.
As I wrote on the request, "_" and "-" are treated the same by PyPI ecosystem. "pip install gogs-client" and "pip install gogs_client" are identical. So IMHO using "python-gogs-client" as the package name is equally correct as "python-gogs_client".
If both names are valid (the name in eg. the URL and the name of the archive), should the other name then be provided?
Sebastian
On 18.8.2017 16:20, Sebastian wrote:
On 08/18/2017 03:34 PM, jan matejek wrote:
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
The issue with your request is the discrepancy in the package's PyPI identifier. Upstream seems to think the name should be "gogs_client", but uploaded as "gogs-client", except the filename is still "gogs_client".
Upstream sometimes does that, and PyPI does nothing to stop them. Such is the world we live in.
As I wrote on the request, "_" and "-" are treated the same by PyPI ecosystem. "pip install gogs-client" and "pip install gogs_client" are identical. So IMHO using "python-gogs-client" as the package name is equally correct as "python-gogs_client".
If both names are valid (the name in eg. the URL and the name of the archive), should the other name then be provided?
Yes please. That didn't occur to me but it is a good idea.
m.
Sebastian
Hi,
On 18.08.2017 15:34, jan matejek wrote:
hello,
On 18.8.2017 10:07, Sebastian wrote:
First there are the generic naming guidelines which say that the dash '-' must not be used "as the delimiter for name parts".[2]
ISTM you misread the part of the wiki, it says quite the opposite: you should use "-" (dash), you should NOT use other separators (such as "_", "+" and ".")
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
The issue with your request is the discrepancy in the package's PyPI identifier. Upstream seems to think the name should be "gogs_client", but uploaded as "gogs-client", except the filename is still "gogs_client".
Upstream sometimes does that, and PyPI does nothing to stop them. Such is the world we live in.
As I wrote on the request, "_" and "-" are treated the same by PyPI ecosystem. "pip install gogs-client" and "pip install gogs_client" are identical. So IMHO using "python-gogs-client" as the package name is equally correct as "python-gogs_client".
There is a difference if we translate pip requirements (eg via metaextract[1]) to rpm requires (assuming that other pip packages use the correct name). The name we should use is then one that is written in the setup.py/setup.cfg file. Which is "gogs_client". So the correct name is imo python-gogs_client .
Best,
Tom
[1] https://pypi.python.org/pypi/metaextract
m.
Hi,
On 18.08.2017 16:26, jan matejek wrote:
On 18.8.2017 16:20, Sebastian wrote:
On 08/18/2017 03:34 PM, jan matejek wrote:
Then there is the more specific naming policy for python packages which says the package must be called "python-$pypiname". It does not mention any exceptions (at least I haven't found any). In the above example the pypi's name is "gogs-client" and results in
The issue with your request is the discrepancy in the package's PyPI identifier. Upstream seems to think the name should be "gogs_client", but uploaded as "gogs-client", except the filename is still "gogs_client".
Upstream sometimes does that, and PyPI does nothing to stop them. Such is the world we live in.
As I wrote on the request, "_" and "-" are treated the same by PyPI ecosystem. "pip install gogs-client" and "pip install gogs_client" are identical. So IMHO using "python-gogs-client" as the package name is equally correct as "python-gogs_client".
If both names are valid (the name in eg. the URL and the name of the archive), should the other name then be provided?
Yes please. That didn't occur to me but it is a good idea.
So we want to Provide now all combinations with - and _ ? Could that be done automatically instead of adding all the Provides manually to every spec file?
Best,
Tom
On 21.8.2017 07:31, Thomas Bechtold wrote:
Yes please. That didn't occur to me but it is a good idea.
So we want to Provide now all combinations with - and _ ?
Definitely not. Only in the few cases where upstream is confused enough to use both, like here. ISTM this is something the packager must know and therefore can add the alternate spelling manually.
m.
Could that be done automatically instead of adding all the Provides manually to every spec file
On 18.8.2017 16:41, Thomas Bechtold wrote:
There is a difference if we translate pip requirements (eg via metaextract[1]) to rpm requires (assuming that other pip packages use the correct name). The name we should use is then one that is written in the setup.py/setup.cfg file. Which is "gogs_client". So the correct name is imo python-gogs_client .
That makes sense and disambiguates the package name. How about this for a policy: Package should be named as python-<setup.py `name` field>. If this is different from PyPI name (e.g. gogs_client as setup.py name, gogs-client as pypi name), then python-<PyPI name> should also be provided.
regards m.
Best,
Tom
[1] https://pypi.python.org/pypi/metaextract
m.
On 21.08.2017 14:37, jan matejek wrote:
On 18.8.2017 16:41, Thomas Bechtold wrote:
There is a difference if we translate pip requirements (eg via metaextract[1]) to rpm requires (assuming that other pip packages use the correct name). The name we should use is then one that is written in the setup.py/setup.cfg file. Which is "gogs_client". So the correct name is imo python-gogs_client .
That makes sense and disambiguates the package name. How about this for a policy: Package should be named as python-<setup.py `name` field>. If this is different from PyPI name (e.g. gogs_client as setup.py name, gogs-client as pypi name), then python-<PyPI name> should also be provided.
Sounds good to me.
Tom
Ok, so this section in the wiki:
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language. could be replace with, for example:
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename must be the name of the package in the package's setup.py, which is equal to the filename of the source tarball. If this differs from the name on the Python Package Index, the official third-party software repository for the Python programming language, the packgage should provide this name too.
And does the Packaging guidelines change process apply here? https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process IMO it does.
Sebastian
On 08/22/2017 05:54 PM, Thomas Bechtold wrote:
On 21.08.2017 14:37, jan matejek wrote:
On 18.8.2017 16:41, Thomas Bechtold wrote:
There is a difference if we translate pip requirements (eg via metaextract[1]) to rpm requires (assuming that other pip packages use the correct name). The name we should use is then one that is written in the setup.py/setup.cfg file. Which is "gogs_client". So the correct name is imo python-gogs_client .
That makes sense and disambiguates the package name. How about this for a policy: Package should be named as python-<setup.py `name` field>. If this is different from PyPI name (e.g. gogs_client as setup.py name, gogs-client as pypi name), then python-<PyPI name> should also be provided.
Sounds good to me.
Tom
On 24.8.2017 09:23, Sebastian wrote:
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename must be the name of the package in the package's setup.py, which is equal to the filename of the source
I would remove the "equal to tarball filename" part. There is no guarantee about that.
tarball. If this differs from the name on the Python Package Index, the official third-party software repository for the Python programming language, the packgage should provide this name too.
better: "package should also provide 'python-<pypi name>'
Maybe also something about packages without setup.py? "When a package doesn't exist on PyPI and no setup.py is present, the <modulename> is left to the packager discretion. Upstream preferred name, tarball name or site-packages directory name are reasonable choices."
And does the Packaging guidelines change process apply here? https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process IMO it does.
We are discussing the change right now, so that can be checked off :) Other than that, let's see. This is a clarification of ambiguity, and for 99 % of packages it does not represent a change.
We *could* test this in rpmlint though. That would catch messed up packages that now definitely exist. We could get a pypi-checker that would also verify Requires against setup.py and requirements.txt (i hereby propose a rpmlint check, that's another point done ;) ) Seriously though, this would be nice, but requires some amount of work for which I definitely don't have the capacity right now. Putting it on the long-term TODO, contributions welcome.
Even as a clarification, it's worth announcing, so we might want to let the Package Guidelines Team know.
I don't think we need to bother with a RFC and a 14-day wait for this; in any case, we can start using the guideline even before "formally accepting", because, again, it's resolving an ambiguity. But of course feel free to send a RFC if you think it should be done.
regards m.
Sebastian
On 08/22/2017 05:54 PM, Thomas Bechtold wrote:
On 21.08.2017 14:37, jan matejek wrote:
On 18.8.2017 16:41, Thomas Bechtold wrote:
There is a difference if we translate pip requirements (eg via metaextract[1]) to rpm requires (assuming that other pip packages use the correct name). The name we should use is then one that is written in the setup.py/setup.cfg file. Which is "gogs_client". So the correct name is imo python-gogs_client .
That makes sense and disambiguates the package name. How about this for a policy: Package should be named as python-<setup.py `name` field>. If this is different from PyPI name (e.g. gogs_client as setup.py name, gogs-client as pypi name), then python-<PyPI name> should also be provided.
Sounds good to me.
Tom
On Thu, Aug 24, 2017 at 3:23 AM, Sebastian sebix@sebix.at wrote:
Ok, so this section in the wiki:
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language. could be replace with, for example:
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename must be the name of the package in the package's setup.py, which is equal to the filename of the source tarball. If this differs from the name on the Python Package Index, the official third-party software repository for the Python programming language, the packgage should provide this name too.
And does the Packaging guidelines change process apply here? https://en.opensuse.org/openSUSE:Packaging_guidelines_change_process IMO it does.
Sebastian
There is another naming issue I wanted to bring up. More and more packages are dropping support for python2. However, other packages that support both python2 and python3 still depend on these packages. So dropping the python2 version entirely is not a good option.
So we need some way to handle the naming of these packages. The simplest way would be to stick with what we did in the past, using "python-foo" and "python3-foo". But this prevents us from using the single-spec macros and makes it impossible to support other python implementations down the road.
So my suggestion is to make the python3 package use the "python-foo" name, using singlespec macros with python2 disabled. The python2 package should be named "python2-foo", should not use singlespec macros, and should provide "python-foo = %{version}".
Does this sound reasonable to everyone?
On 24.8.2017 16:52, Todd Rme wrote:
There is another naming issue I wanted to bring up. More and more packages are dropping support for python2. However, other packages that support both python2 and python3 still depend on these packages. So dropping the python2 version entirely is not a good option.
So we need some way to handle the naming of these packages. The simplest way would be to stick with what we did in the past, using "python-foo" and "python3-foo". But this prevents us from using the single-spec macros and makes it impossible to support other python implementations down the road.
So my suggestion is to make the python3 package use the "python-foo" name, using singlespec macros with python2 disabled. The python2 package should be named "python2-foo", should not use singlespec macros, and should provide "python-foo = %{version}".
Does this sound reasonable to everyone?
+1 on using "python-foo" for singlespec package and "python2-foo" for the older version.
Unsure about the provides. With the python3-as-default, we might switch over to providing python-foo from python3 -- in order to capture over users asking for "python-foo". OTOH, there is still the option of disfavoring "python-foo" names altogether, in which case it possibly makes sense to explicitly provide them for backwards compatibility?
m.
On Thu, Aug 24, 2017 at 11:42 AM, jan matejek jmatejek@suse.com wrote:
On 24.8.2017 16:52, Todd Rme wrote:
There is another naming issue I wanted to bring up. More and more packages are dropping support for python2. However, other packages that support both python2 and python3 still depend on these packages. So dropping the python2 version entirely is not a good option.
So we need some way to handle the naming of these packages. The simplest way would be to stick with what we did in the past, using "python-foo" and "python3-foo". But this prevents us from using the single-spec macros and makes it impossible to support other python implementations down the road.
So my suggestion is to make the python3 package use the "python-foo" name, using singlespec macros with python2 disabled. The python2 package should be named "python2-foo", should not use singlespec macros, and should provide "python-foo = %{version}".
Does this sound reasonable to everyone?
+1 on using "python-foo" for singlespec package and "python2-foo" for the older version.
Unsure about the provides. With the python3-as-default, we might switch over to providing python-foo from python3 -- in order to capture over users asking for "python-foo". OTOH, there is still the option of disfavoring "python-foo" names altogether, in which case it possibly makes sense to explicitly provide them for backwards compatibility?
I think the best solution long-term would be disfavor "python-foo" in favor of "python2-foo", but have "python2-foo" provide/obsolete "python-foo".
I would be strongly against having "python3-foo" obsolete/provide "python-foo", that would break both packages and users own scripts.
On 24.8.2017 18:03, Todd Rme wrote:
I would be strongly against having "python3-foo" obsolete/provide "python-foo", that would break both packages and users own scripts.
I don't see how that breaks user scripts? Do we expect someone to rely on package names in a way that would also touch custom scripts?
As for breaking packages, that is true. OTOH, I will be doing a conversion run on Factory to replace all "python-foo" with a versioned require anyway. (I intend to first replace with "python3-foo", see what breaks, then revert to "python2-foo" where python3 is not supported)
I admit that i'm biased towards breaking things ;) Mainly for the sake of discovering *what exactly* breaks and if we actually need to have it.
OTOH, maybe some rpmlint and submission checks are sufficient for this purpose and we can keep old packages untouched.
regards m.
On Thu, Aug 24, 2017 at 12:23 PM, jan matejek jmatejek@suse.com wrote:
On 24.8.2017 18:03, Todd Rme wrote:
I would be strongly against having "python3-foo" obsolete/provide "python-foo", that would break both packages and users own scripts.
I don't see how that breaks user scripts? Do we expect someone to rely on package names in a way that would also touch custom scripts?
They will break because their python2 dependencies will automagically be deleted and replaced by python3 versions.
As for breaking packages, that is true. OTOH, I will be doing a conversion run on Factory to replace all "python-foo" with a versioned require anyway. (I intend to first replace with "python3-foo", see what breaks, then revert to "python2-foo" where python3 is not supported)
I admit that i'm biased towards breaking things ;) Mainly for the sake of discovering *what exactly* breaks and if we actually need to have it.
OTOH, maybe some rpmlint and submission checks are sufficient for this purpose and we can keep old packages untouched.
A lot of packages are unsupported upstream. They will never support python3, and having to go through and modernize all those packages seems like a huge amount of work for little or no real benefit to anyone. I would rather just let them bitrot until they break and remove them then.
-
jan matejek -
jan matejek -
Sebastian -
Thomas Bechtold -
Todd Rme