Python packages naming rules

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Python packages naming rules

Sebastian-2
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

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-4
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.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

Sebastian-2
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

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-5


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
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

Thomas Bechtold
In reply to this post by jan matejek-4
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.
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

Thomas Bechtold
In reply to this post by jan matejek-5
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

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-5


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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-4
In reply to this post by Thomas Bechtold
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.
>>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

Thomas Bechtold


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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

Sebastian-2
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

--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers



signature.asc (871 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-5


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
>
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

todd rme
In reply to this post by Sebastian-2
On Thu, Aug 24, 2017 at 3:23 AM, Sebastian <[hidden email]> 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?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-4
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.

>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

todd rme
On Thu, Aug 24, 2017 at 11:42 AM, jan matejek <[hidden email]> 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.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

jan matejek-4
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.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python packages naming rules

todd rme
On Thu, Aug 24, 2017 at 12:23 PM, jan matejek <[hidden email]> 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.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]