[Guido]
You shouldn't see site-python or site-packages, they only exist on Unix.
[Gordon]
You mean "they only exist _for_ Unix", (site.py looks for them on Windows).
No it doesn't. The code in site.py only adds site-packages and site-python when os.sep is '/'. RTSL.
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.
What do you mean by "the same mechanism should work"? The same mechanism for what? Are you talking about sharing the installed files somehow?
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".
Fair enough. Of course I know about .pth files so I unzipped them elsewhere and added a .pth file pointing there...
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.
The .pth files are designed for this. Maybe they haven't been explained as well as they should.
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.
It's not Mark's fault, it's Microsoft's fault. If you don't do things the way MS wants you to, experienced Windows users will gripe, misunderstand what you do, etc.
And no, I don't have any solutions to this, I'm just griping...
Ditto. Understanding the problems is half of the solution though. The problems seem pretty complex! --Guido van Rossum (home page: http://www.python.org/~guido/)