But site-packages IS empty!! Stuff end up there when users put them there! I don't see what the problem is? If you have trouble with site-packages, why do you install stuff there?
Personally, i usually bundle third-party modules with my software. Some things that are more "standard library-like" and that i trust to be stable i install through the packaging system. Kind of like what you propose. I've been doing this for years without problems. So i don't see what you are complaining about.
And frankly, a lot of your arguments are not really specific to python, and can be applied to /usr/lib and shared libraries in general. So this is just the old static versus dynamic linking argument all over again, and the same arguments apply.
And on the flip-side -- if you don't want trust site-packages, your startup script can rip it out of sys.path...# Patrick Maupin
+1 to Fredrik! I also have to throw in agreement with Ken that the whole setuptools is quite frustrating when it doesn't work. I actually chose to write a scraper with Perl's WWW::Mechanize over the Python equivalent because setuptools did not work correctly on OS 10.4.4. I simply failed, downloading the same packages over and over; never recognizing that things were installed. This is better than distutils how?! I like Python. I prefer Python. It physically hurt that I had to use Perl to get my job done.
Frankly, I really don't care where things are installed as long as it's consistent, customizable, and usable. setuptools and ez_install failed for me. It may have been designed to be easy to use, but it wasn't consistent and certainly wasn't usable. Perhaps in time, they'll work the bugs out. However, I still prefer having the option to use simple distutils setups to install my Python software.
Does this not work for you?
python setup.py easy_install --no-deps .
I'm curious why not. (Just didn't know it existed perhaps?... it is documented in the very module you're complaining about, but perhaps I should make it more prominent.)
Two other points:
- The project you complain about is mine and hasn't been releasing very often recently (I must fix my crappy release scripts). Also, the use of setuptools by that project is new. So, I put my hands up and admit that the failure could easily be my fault, not setuptools'.
- If you get time, a bug report is welcome! (Send it to me -- if it's setuptools' fault, I'll forward the bug report along)
Certainly a lot of these issues exist outside of Python. However, we can solve them in Python, whether or not they are solved elsewhere.
I can figure this out for myself, and I feel we're getting close to where we need to be at work. The problem though is that, having figured it out, the only way to express this is as a bunch of additions and configurations to the system, some practices, and some guards. I just want us to agree on a good way that people should do this -- it's not a technical issue. And the tools should not just support that practice, but encourage it, with one set of conventions.
Right now one of the reasons some people balk at setuptools is because it solves problems they have already been solving on their own with hacked setup.py files and sys.path hacks. Setuptools breaks a lot of these hacks (it tries really hard not to break too many, but it is inevitable), since it is actually trying to come up with an inclusive way to do these things. I think some people have become comfortable with their own practices, and have forgotten that other people don't use those practices, don't know what those practices are, and don't have any tools to help them go down that path. So, that's what I'm complaining about -- the default distutils configuration, and the default sys.path, and the default site.py, all encourage bad practice. They don't stop you from doing things the right way, but they don't help either.# Ian Bicking