<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi <<a href="mailto:a.badger@gmail.com">a.badger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer <<a href="mailto:nas-python@arctrix.com" target="_blank">nas-python@arctrix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-02-26, Gregory P. Smith wrote:<br>
> On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw <<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>> wrote:<br>
> For an OS distro provided interpreter, being able to restrict its use to<br>
> only OS distro provided software would be ideal (so ideal that people who<br>
> haven't learned the hard distro maintenance lessons may hate me for it).<br>
<br></blockquote><div>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.</div><div><br></div><div>Why might someone need to use the distro provided interpreter?</div><div><br></div><div>* 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.</div><div>* 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.</div><div><br></div><div>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.</div><div><br></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>I'd go a <i>little</i> 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.</div><div><br></div><div>-gps</div></div></div>