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
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