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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4