> [Gordon] > > That would work fine. One of the standalone configurations will > > write a site.py, but that's for a completely self-contained > > installation (ie, one which will have no conflicts with another > > Python installation). > > > > I'd also note that, for Windows at least, the path-expanding > > mechanism created by site.py has not caught on. I've got lots > > installed, and no site-python, site-packages or sitecustomize. [Guido] > You shouldn't see site-python or site-packages, they only exist > on Unix. You mean "they only exist _for_ Unix", (site.py looks for them on Windows). I don't like that. For one thing, modulo a few platform differences, the same mechanism should work for multi-user Unix and Windows LAN installations. And single- user Windows (I know, redundant, even on NT) should be a degenerate case of the above. > On Windows, everything is installed in the top Python > directory. However you should see .pth files there, which is > what site.py looks for. I believe NumPy and PIL use those. No NumPy, no PIL, no .pth files. 99% of everything out there just says "unzip this somewhere on your Python path". In this case, Jim Ahlstrom may be right - there are too many options, or at least an insufficiently emphasized "proper" method. Until I worked out my own way of installing stuff, I used to lose a large number of packages whenever I upgraded my Windows Python. Much as I love Mark's stuff (and hesitate to criticize crazy Aussies), I wish there weren't so much special casing here for Windows. And no, I don't have any solutions to this, I'm just griping... - Gordon
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