On Sun, Apr 13, 2008 at 02:04:56PM -0400, Phillip J. Eby wrote: > At 05:29 PM 4/13/2008 +0200, Gael Varoquaux wrote: >> Of course setuptools will >> break this, because it adds itsef to front of the PYTHONPATH, and totally >> break the PYTHONPATH semantics (Grrr). > > The entire point of PYTHONPATH is to be able to put things at the front of > it, so I don't see how that's breaking anything.
Well actually, my phrasing in the above was catastrophic. I have mixed PYTHONPATH and sys.path. Anyhow, I have a problem with how setuptools deals with both: * sys.path > When you ask easy_install to install something as the default importable > version of that package, the only way to ensure that is by placing that > thing at the front of sys.path, to override any other version of it that > might be installed elsewhere on sys.path. What I would want is setuptools to respect the priorities for packages depending on where they are installed. In other words, if I install a package in /usr/local/lib and this is further down the priorities than /usr/lib, then I don't expect this package to override module imports happening from /usr/lib. You can justify what setuptools is doing from an implementation point of view, but it doesn't change the fact that it is doing the wrong thing. Wrong because it goes against what Python does. Thus I have to learn some completely new import semantics to deal with the fact that some of the packages on my system where installed by setuptools. In addition there is a good reason behind the standard Python behavior. * PYTHONPATH With standard Python, I can override the import mechanism using the PYTHONPATH. This way I can make sure that the modules I want get imported. And pretty much all the programs I can think of with a path environment variable behave like this. Now if I have a module installed with setuptools, I no longer have the possibility to do this, because setuptools inserts it self before the PYTHONPATH. First of all this really breaks the users expectancies. Second it puts people in a dead end. Actually it forces them to use setuptools, or to monkey-patch sys.path themselves, to override the import of a module. Once again you are expecting your users to know way more than a beginner's knowledge of Python. Python is simple and does what you expect... no longer. This is way worse than not respecting sys.path priorities. I have lost hours on that, and when I found out why, ... well I won't copy my remarks about setuptools on this mailing list. And what has happened to me has probably happened to many. This second problem could probably easily be fixed, though, by some more clever monkey patching of the sys.path. Actually both problems are solvable, if you care about not changing the way Python works. If you don't care, than make it obvious everywhere. But even if you do, I think it is a very bad thing, because people will still fall for the trap (eg I copy my scripts to a new server, which uses setuptools, although I don't know it, and I actually don't know what setuptools are). Don't call it Python, if you are going to change fundamentally the way it works. My 2 cents, Gaël _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
