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 distro. 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? Cheers, Nick. -- 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
