On 07Jul2016 0624, Barry Warsaw wrote:
On Jul 07, 2016, at 08:12 AM, Eric V. Smith wrote:
One thing to keep in mind if we do this is how it interacts with the -S command line option to not include site-packages in sys.path. I currently use -S to basically mean "give my python as it was distributed, and don't include anything that was subsequently added by adding other RPM's (or package manager of your choice)". I realize that's a rough description, and possibly an abuse of -S. If using -S were to start excluding parts of the stdlib, that would be a problem for me.
It's an important consideration, and leads to another discussion that's recurred over the years. Operating systems often want an "isolated" Python, similar to what's given by -I, which cannot be altered by subsequent installs. It's one of the things that lead to the Debian ecosystem using dist-packages for PyPI installed packages. Without isolation, it's just too easy for some random PyPI thing to break your system, and yes, that has really happened in the past.
So if we go down the path of moving more of the stdlib to site-packages, we also need to get serious about a system-specific isolated Python.
I've done just enough research to basically decide that putting any of the stdlib in site-packages is infeasible (it'll break virtualenv/venv as well), so don't worry about that. A "dist-packages" equivalent is a possibility, and it may even be possible to manage these packages directly in Lib/, which would result in basically no visible impact for anyone who doesn't care to update individual parts. Cheers, Steve
Cheers, -Barry