Bug#791635: python-policy: Please require namespacing source python module packages

[Guillem Jover]

Control: reopen -1
Control: reassign -1 python3

[ Sorry, resending, as the bug was archived so it ignored all the
control commands. ]

This got closed due to the python-defaults package being removed from
sid, reopening and reassigning where python-policy seems to be located
now.

Date: Tue, 7 Jul 2015 03:11:06 +0200
Subject: python-policy: Please require namespacing source python module
packages
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FROMDEVELOPER,
RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham autolearn_force=no
version=3.4.0-bugs.debian.org_2005_01_02
Source: python-defaults
Source-Version: 2.7.9-1
Severity: wishlist
Hi!
Given recent ITP discussions [0] about lack of namespacing on python
module source package names, I think it would be really good to fix
this at the source, by mandating it in the python-policy. Attached is
a proposal wording.
[0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog
Thanks,
Guillem
=== modified file 'debian/python-policy.sgml'
--- debian/python-policy.sgml 2015-02-27 23:09:27 +0000
+++ debian/python-policy.sgml 2015-07-06 19:58:13 +0000
@@ -513,7 +513,9 @@
to use this prefix for all packages with public modules as they may
be used by other packages in the future. Python 3 modules must be
in a separate binary package prefixed with <var>python3-</var> to
- preserve run time separation between python and python3.
+ preserve run time separation between python and python3. When the
+ source package only produces python module binary packages, it must
+ also be prefixed with <var>python-</var>.
The binary package for module foo should preferably be named
<package>python-<var>foo</var></package>, if the module name

Thanks,
Guillem

[Scott Kitterman]

Do we really have to have this argument again? Let's not. Please wontfix and let's move on.

Personally, I maintain 25 packages in the team that would need renaming. I'm not sure how many total there are, but they'd all have to go through New again.

It'd be much simpler just to drop DPT or myself from uploaders and ignore this, so that's probably the path I would take.

Regardless, I don't think this is an appropriate use of FTP Team time/energy.

Also, as I've said before on this topic, every packaging rule is a barrier to entry for new contributors. We really shouldn't add things that aren't needed.

Scott K

Post by Guillem Jover
Control: reopen -1
Control: reassign -1 python3
[ Sorry, resending, as the bug was archived so it ignored all the
control commands. ]
This got closed due to the python-defaults package being removed from
sid, reopening and reassigning where python-policy seems to be located
now.

Date: Tue, 7 Jul 2015 03:11:06 +0200
Subject: python-policy: Please require namespacing source python module
packages
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FROMDEVELOPER,
RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham autolearn_force=no
version=3.4.0-bugs.debian.org_2005_01_02
Source: python-defaults
Source-Version: 2.7.9-1
Severity: wishlist
Hi!
Given recent ITP discussions [0] about lack of namespacing on python
module source package names, I think it would be really good to fix
this at the source, by mandating it in the python-policy. Attached is
a proposal wording.
[0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog
Thanks,
Guillem
=== modified file 'debian/python-policy.sgml'
--- debian/python-policy.sgml 2015-02-27 23:09:27 +0000
+++ debian/python-policy.sgml 2015-07-06 19:58:13 +0000
@@ -513,7 +513,9 @@
to use this prefix for all packages with public modules as they may
be used by other packages in the future. Python 3 modules must be
in a separate binary package prefixed with <var>python3-</var> to
- preserve run time separation between python and python3.
+ preserve run time separation between python and python3. When the
+ source package only produces python module binary packages, it must
+ also be prefixed with <var>python-</var>.
The binary package for module foo should preferably be named
<package>python-<var>foo</var></package>, if the module name

Thanks,
Guillem

[Stefano Rivera]

Hi Scott (2023.01.29_01:34:54_+0000)

Post by Scott Kitterman
It'd be much simpler just to drop DPT or myself from uploaders and ignore this, so that's probably the path I would take.

The Debian Python Policy is independent of DPT. So, if adopted, that
wouldn't help much... :)

Post by Scott Kitterman
Regardless, I don't think this is an appropriate use of FTP Team time/energy.

+1. I could live with this being a recommendation for new source
packages, but it don't really see the value in renaming existing source
packages.

SR

[Guillem Jover]

Hi!

[ I never received a reply so was not aware some conversation had been
going on. :) I've rearranged the replies a bit. ]

tags 791635 + wontfix
thanks
[Scott Kitterman, 2023-01-29]

Post by Scott Kitterman
Please wontfix and let's move on.

+1
IMO source package names should follow upstream as closely as possible

If Debian only contained python packages, that would make sense,
because python modules upstream need to care about not stomping over
each others names. But Debian contains source packages for multitude of
projects and language ecosystems, where their own modules can and do
share the same short and generic or conflicting module names with many
other language ecosystems modules (say json modules). These also can
conflict with command-line tools which use another common namespace, etc.

Pretty much every other language specific team in Debian namespaces
their _source_ and _binary_ packages to avoid stomping/grabbing on
the global namespace. I don't really understand what makes python
special here, that it cannot follow a similar pattern. :/

Post by Scott Kitterman
Hi Scott (2023.01.29_01:34:54_+0000)

Post by Scott Kitterman
Regardless, I don't think this is an appropriate use of FTP Team
time/energy.

I was under the impression that these did still not require NEW trips,
or had not associated that the dak support for overrides for sources
implied that renames for these now (obviously) need to go through NEW,
until Scott mentioned this on d-d (thanks!). Which while it makes
sense that they'd also go through NEW, it now implies cleanups like
this cannot be easily done w/o going through additional hoops.

I do think though that this kind of thing is precisely what a NEW check
should be doing (and used to imply too, long ago AFAIR), as the archive
admins are responsible for both the contents (f.ex. license-wise),
organization (overrides) and the *namespace* of the packages in the
archive.

Post by Scott Kitterman
+1. I could live with this being a recommendation for new source
packages, but it don't really see the value in renaming existing source
packages.

I definitely think any changes ought to be new packages only.
I could live with "upstream name or python-$modulename" for the source
package. Generally when I've deviated from python-$modulename it's been to
align to the upstream naming convention.

I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is something
like "py<something>" or some widely known sub-ecosystem that is
really very much python-specific, and there is no chance of that ever
being present in other language ecosystems (which ahem), then I guess
that could be fine, but it's hard to tell from just "upstream name",
given what I've seen. :)

The above, and restricting to only new source packages, still seems
rather unsatisfactory to me, in terms of namespace handling, and
management of such shared resource. But, assuming the "upstream name"
part can be made less fuzzy, I'd take a policy that stops making the
problem worse, and which applies only to new source packages, than
none at all. I can try to propose new wording.

Post by Scott Kitterman
Also, as I've said before on this topic, every packaging rule is a
barrier to entry for new contributors. We really shouldn't add
things that aren't needed.

See above for the reasoning. I can relate to that in the extreme, but
to me the key is that managing namespaces is precisely one of the
essential things a distribution does and needs to do, as part of its
integration and cohesion work to make all those random and disparate
parts that we are gluing together work in concert, and in a way that
is easier to understand and handle at scale.

Thanks,
Guillem

[Simon McVittie]

Post by Guillem Jover
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is something
like "py<something>" or some widely known sub-ecosystem that is
really very much python-specific, and there is no chance of that ever
being present in other language ecosystems (which ahem), then I guess
that could be fine

src:dbus-python, src:tap.py and src:pygobject seem like some examples of
upstream names that are fine (not going to conflict with other ecosystems)
despite not fitting the /^python-/ pattern.

But, looking at some packages that I happen to have installed, I think
I agree with Guillem that names like src:alabaster and src:binaryornot
seem too generic to be ideal.

smcv

[Scott Kitterman]

Post by Simon McVittie

Post by Guillem Jover
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is something
like "py<something>" or some widely known sub-ecosystem that is
really very much python-specific, and there is no chance of that ever
being present in other language ecosystems (which ahem), then I guess
that could be fine

src:dbus-python, src:tap.py and src:pygobject seem like some examples of
upstream names that are fine (not going to conflict with other ecosystems)
despite not fitting the /^python-/ pattern.
But, looking at some packages that I happen to have installed, I think
I agree with Guillem that names like src:alabaster and src:binaryornot
seem too generic to be ideal.

I think forcing a bunch of renaming for existing packages is a waste of effort. If there is a namespace problem it has already happened. For specific cases where there's an actual conflict to resolve, we should do that. For the theoretical cases, we should leave them alone.

I don't have any objection to a new requirement for the name being distinctive for new source packages, but I don't think we should specify exactly the name that's required.

It's not reasonable to assume that all FTP Team members that might review a package in New are familiar with all language specific policies in Debian. If you want to have the FTP Team enforce something, it needs to go in Debian policy. This is probably feasible as a generic rule about language specific implementations having source and binary package names that don't squat on generic names.

Scott K

[Matthias Klose]

Post by Scott Kitterman

Post by Simon McVittie

Post by Guillem Jover
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is something
like "py<something>" or some widely known sub-ecosystem that is
really very much python-specific, and there is no chance of that ever
being present in other language ecosystems (which ahem), then I guess
that could be fine

src:dbus-python, src:tap.py and src:pygobject seem like some examples of
upstream names that are fine (not going to conflict with other ecosystems)
despite not fitting the /^python-/ pattern.
But, looking at some packages that I happen to have installed, I think
I agree with Guillem that names like src:alabaster and src:binaryornot
seem too generic to be ideal.

I think forcing a bunch of renaming for existing packages is a waste of effort. If there is a namespace problem it has already happened. For specific cases where there's an actual conflict to resolve, we should do that. For the theoretical cases, we should leave them alone.
I don't have any objection to a new requirement for the name being distinctive for new source packages, but I don't think we should specify exactly the name that's required.
It's not reasonable to assume that all FTP Team members that might review a package in New are familiar with all language specific policies in Debian. If you want to have the FTP Team enforce something, it needs to go in Debian policy. This is probably feasible as a generic rule about language specific implementations having source and binary package names that don't squat on generic names.

there are also packages with it's own naming schema, like sphinx-*, or
tryton-*. No needs to rename these sources.

[Stefano Rivera]

Hi Guillem (2024.10.18_13:31:26_+0000)

Post by Guillem Jover

IMO source package names should follow upstream as closely as possible

If Debian only contained python packages, that would make sense,
because python modules upstream need to care about not stomping over
each others names. But Debian contains source packages for multitude of
projects and language ecosystems, where their own modules can and do
share the same short and generic or conflicting module names with many
other language ecosystems modules (say json modules). These also can
conflict with command-line tools which use another common namespace, etc.
Pretty much every other language specific team in Debian namespaces
their _source_ and _binary_ packages to avoid stomping/grabbing on
the global namespace. I don't really understand what makes python
special here, that it cannot follow a similar pattern. :/

It's worth drawing a distinction between libraries and apps here.

I think it would be silly to namespace application source packages that
are already installing a binary of that name. The fact that they are
implemented in Python is hardly relevant. It's easier for everyone when
the source and binary package names are the same, and match upstream's
name.

In general, namespacing libraries makes sense. Either with python- or
whatever ecosystem they are part of.

Stefano