Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

On 2/28/19 6:56 PM, Gregory P. Smith wrote:

On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi mailto:a.badger@gmail.com> wrote:

On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer mailto:nas-python@arctrix.com> wrote:

On 2019-02-26, Gregory P. Smith wrote: > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw mailto:barry@python.org> wrote: > For an OS distro provided interpreter, being able to restrict its use to > only OS distro provided software would be ideal (so ideal that people who > haven't learned the hard distro maintenance lessons may hate me for it).

This idea has some definite problems.  I think enforcing it via convention is about as much as would be good to do.  Anything more and you make it hard for people who really need to use the vendor provided interpreter from being able to do so.

Why might someone need to use the distro provided interpreter?

* Vendor provides some python modules in their system packages which are not installable from pip (possibly even a proprietary extension module, so not even buildable from source or copyable from the system location) which the end user needs to use to do something to their system. * End user writes a python module which is a plugin to a system tool which has to be installed into the system python to from which that system tool runs.  The user then wants to write a script which uses the system tool with the plugin in order to do something to their system outside of the system tool (perhaps the system tool is GUI-driven and the user wants to automate a part of it via the python module).  They need their script to use the system python so that they are using the same code as the system tool itself would use.

There's probably other scenarios where the benefits of locking the user out of the system python outweigh the benefits but these are the ones that I've run across lately.

Agreed.  The convention approach as someone said RHEL 8 has apparently done with an os distro reserved interpreter (yay) is likely good enough for most situations.

I'd go a /little/ further than that and suggest such an os distro reserved interpreter attempt to prevent installation of packages (ie: remove pip/ensurepip/distutils) via any other means than the OS package manager (rpms, debs).  Obviously that can't actually prevent someone from figuring out how to run getpip or manually installing trees of packages within its sys.path, but it acts as a deterrent suggesting that this interpreter is not intended for arbitrary software installation.

Currently, in RHEL/Fedora: - "sudo pip" installs to /usr/local/, RPM packages install to /usr/ - with "-I", the interpreter does not look into /usr/local/. AFAIK, Debian/Ubuntu have something very similar, and were first to do it. What remains to tie this together is making "platform-python" always run with -I. This is PEP 432's "system-python" use case / design goal. (The RHEL/Fedora platform-python was initially called system-python. We renamed to it so it doesn't clash with the PEP. It's the same use case, but we don't want to assign semantics to the name prematurely. Cutrrently, system-python is waiting for the larger-scale restructuring, and hopefully wider/longer discussion.)