Movatterモバイル変換
[0]ホーム
[Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]
Petr Viktorinencukou 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-Devmailing list
[8]ページ先頭