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

[Petr Viktorin]

On 2/28/19 6:56 PM, Gregory P. Smith wrote:
> 
> On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi <a.badger at gmail.com 
> <mailto:a.badger at gmail.com>> wrote:
> 
> 
>     On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer
>     <nas-python at arctrix.com <mailto:nas-python at arctrix.com>> wrote:
> 
>         On 2019-02-26, Gregory P. Smith wrote:
>          > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw
>         <barry at python.org <mailto:barry at 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.)