A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-July/090690.html below:

[Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376

[Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view] [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]P.J. Eby pje at telecommunity.com
Sat Jul 18 22:22:37 CEST 2009
At 04:07 PM 7/18/2009 -0400, Jim Jewett wrote:
>Michael Foord wrote:
> >> I agree. People with versioning issues *should* be using virtualenv.
>
>Tarek Ziadé replied (and several people later agreed)
> > Let's remove site-packages from Python then.
>
>What about those people *without* versioning issues?
>
>I have no qualms suggesting that package management programs avoid the
>use of site-packages.  Such programs do need to cater to edge cases.
>
>But a single drop-it-in directory works great for the vast majority of
>*my* needs; requiring me to drink the Kool-Aid from a specific package
>management system just to get access to any add-ons -- even those I
>wrote myself in pure python -- would be a huge step backwards.

IIUC, the new "user" directories supported by the 'site' module would 
fill this purpose.  That is, rather than having a site-wide packages 
directory, there'd just be the user-specific package directories.

(That having been said, I'm not actually in favor of the idea.)

More information about the Python-Dev mailing list

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