[Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]
encukou at gmail.com
Fri Mar 1 05:41:03 EST 2019
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.)
More information about the Python-Dev