On 2/28/19 6:56 PM, Gregory P. Smith wrote:
On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi <a.bad...@gmail.com
<mailto:a.bad...@gmail.com>> wrote:
On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer
<nas-pyt...@arctrix.com <mailto:nas-pyt...@arctrix.com>> wrote:
On 2019-02-26, Gregory P. Smith wrote:
> On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw
<ba...@python.org <mailto:ba...@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.)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
