On 08/10/2017 02:49 AM, Ben Rosser wrote:
This is following up on a brief conversation I was part of in IRC
I've never been quite sure how to name packages written in Python when
they are just applications. Many "applications" written in Python
still install themselves using distutils or setuptools, and so install
a "module" into the site_packages directory. By a strict
interpretation of our Python packaging guidelines  , python 3
"modules" MUST be packaged as "python3-name".
Since technically any nontrivial Python application that can be
installed via distutils or setuptools likely installs a module, this
strict interpretation of the guidelines would mean that software that
happens to be written in Python but does not intend to provide a
library must be named with the python3-* prefix.
I am not sure that this is intended (since there's definitely software
in the distribution written in Python not named with a python prefix).
If this is not intended, then it would be nice if we could reword the
guideline to be more clear.
If it is intended, I'm prepared to argue that the current guideline is
too strict and should be revisited, both from a practical position
(users looking for software called "foobar" who many not care whether
or not it's written in Python will be confused if it is packaged under
the name "python-foobar" in Fedora), and from a philosophical one (we
don't put the "lib" prefix on every library package if upstream
doesn't use that as their name because we generally try to respect the
way upstream names their software).
You're right that this is currently missing from the guidelines. Would
you be interested in writing up a draft change?
Python modules are a special case of "Addon Packages" :
> If a new package is considered an "addon" package that
> enhances or adds a new functionality to an existing Fedora
> package without being useful on its own, its name should >
> reflect this fact.
So, if you're not extending Python, but providing a standalone app, you
don't need to use the python3- prefix.
Specifically, the de-facto policy (which we should write down) is that
if nothing else is expected to import the module, then don't use the
python3- prefix. So, by not using the prefix, you're signaling that the
Python module is an implementation detail and can be removed (or moved,
for example to a different Python implementation) at any time.
If others *are* expected to import the module, some people make a
"python3-foobar" sub-package, and make the main "foobar" package require it.
As a counter-proposal I would suggest that, as we currently do, we
require the python3-prefix to be provided by the package, but
explicitly leave it to the packager+reviewer's discretion whether or
not the prefix must be part of the real name, too. Some other
languages do already do this: nodejs  and ocaml  both explicitly
have "if this primarily provides a tool or application" clauses in
their naming guidelines. I think it makes sense to have something
similar for Python, to help avoid confusion.
That's a nice idea.
I'll note that modules installed using Python's mechanisms (setuptools,
flit, pip, etc.) automatically provide "python3dist(name)". If we write
new guidelines, I think we should promote that rather than the
python-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org