Re: Bug#790399: ITP: structlog -- tructured Logging for Python
On Wed, 2015-07-01 at 02:58:41 +0100, Filippo Giunchedi wrote:
> On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote:
> > On Mon, Jun 29, 2015 at 10:22:30AM +0200, Adrien CLERC wrote:
> > > Le 29/06/2015 02:51, Filippo Giunchedi a écrit :
> > > > * Package name : structlog
> > > It seems to be a Python library (in the main site, I can read that it is
> > > used as an imported module), it should be named python-structlog.
> > Not necessarily (as we are talking about the source package name).
> indeed, most python modules I've looked at so far don't have the python-
> prefix in their name
I've always considered this a bad practice that I'd really like, we as
a project, stopped perpetuating.
One of the most (if not the most) important resource a distribution has
to curate and arbitrate over is namespaces of many kinds, source/binary
package names, version strings, filesystem objects, exposed APIs, etc.
Here's a relevant snippet from a reply I sent on the bash8 ITP #748383:
Also just following upstream when it comes to naming be it for source
or binary packages is not wise in many cases. Lots of upstreams create
packages or language modules in language silos, where those names are
implicitly namespaced by being part of that language community/portal
for example. Having Http be a perl module is fine, the same for a
python or ruby module, not so much when it comes to integrating it
in a general purpose distribution. Why should the http source package
name be the perl implementation? Even if that source provided modules
for many languages, why should it take over the canonical protocol
name for its source package? Also the source package name is really
pretty visible in many places in the distribution.
The current practice of many python modules to just use the upstream
name as the source package name is a namespace grab, wrong and unfair
to the rest of the distribution, some quick examples to illustrate:
appdirs argvalidate audioread distlib
I wish other language teams in Debian followed the perl lead here.
This also grabs the non-namespaced name for actual possible programs
I'll be filing a bug on the python-policy document to request that
binary *and* source packages be namespaced.