On 10 August 2017 at 10:49, Ben Rosser <rosser....@gmail.com> wrote:
> 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 [3] and ocaml [4] 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.

This is technically already the de facto policy (if it wasn't, a lot
of Fedora's build tooling would have very different names), but the
Python packaging policy doesn't spell it out explicitly.

So while I think you're right that we should make it officially that
it's OK for application packagers to let it be an implementation
detail whether something is written in Python or not, I also think we
would ideally take more steps than we do today to make sure that such
use of Python actually *is* an implementation detail, rather than
something that can leak out and cause compatibility issues with
upstream Python modules.

For example, some time ago, the "mock" command line tool had to rename
its supporting Python package to "mockbuild" in order to resolve a
file conflict when the python-mock package was first added to the

In that vein, the potentially more robust approach I've been
considering for managing that kind of situation is the idea of
recommending that these "the use of Python is an implementation
detail" applications be restructured to take advantage of the native
virtual environment support in Python 3 in order to put their
application specific modules in a private virtual environment, rather
than installing them directly into the system Python as generally
importable packages.

Specifically, having venv available by default allows us to do this as
part of an RPM build:

1. Use "python3 -m venv --system-site-packages --without-pip
<the_venv_dir>" to create an empty symlinked virtual environment that
can see system packages
2. From *outside* the venv, run "pip3 install --prefix <the_venv_dir>"
to install the application specific module(s)
3. Copy any generated "bin" scripts out into the FHS binary directory
(their shebang lines will automatically be set up to auto-activate the
private venv, since they'll reference the venv's Python symlink, *not*
the system level path)

Having a private venv like that available would also give application
packagers a relatively clean way to inject "before anything else runs"
behaviour via *.pth files, which will let them do things like
implicitly adjusting sys.path to include additional directories, as
well as tinkering with __main__.__requires__ in order to manipulate
the behaviour of pkg_resources parallel loading support.

The main reason I hadn't gotten around to actually proposing that is
that there are a few significant open questions where I'm not sure
what the right answer would be:

1. Where would these private venvs actually live?
2. Does the answer to (1) differ for pure Python app modules vs binary
extension modules?
3. Would we allow daisy chaining of these private venvs via *.pth
files? (see https://github.com/berdario/pew#add)
4. How would we make this manageable across Fedora/EPEL/SCLo spec files?


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Reply via email to