At 03:14 PM 7/8/2005 -0400, Kevin Dangoor wrote:
This is a very handy conversation... it coincides with work I'm doing quite nicely.
On 7/8/05, Phillip J. Eby <pje@telecommunity.com> wrote:
FYI, --script-dir defaults to --install-dir if you explicitly set --install-dir, so the above could read:
python setup.py develop --install-dir=../buildutils -m
or for the ultimate in cryptic brevity:
python setup.py develop -md../buildutils
:)
This is a good trick. Unfortunately, it's not working for me. ... Removing the older egg from the easy-install.pth file fixed this problem... I was able to find the new version that was linked in just fine.
Sounds like it is working for you, then. :) Seriously, pkg_resources is very conservative right now about versioning; if you install something without the -m flag, then you are telling it that that is the version you want to use, period. Part of the problem is that pkg_resources adds new versions to the *end* of sys.path, which means that if you have an older version already on sys.path when you ask for the newer one, there's no way that pkg_resources can safely change the path to allow the new version to take effect. The moral is that you probably want to use -m even for site-packages installations, unless there's a good reason to do otherwise. The reason -m doesn't get used by default for site-packages is because I want people whose use case is just "install this thing and make it work like I'm used to" to have a good experience with EasyInstall. :) Conversely, I figure smart people like you will know (or learn) that they want --multi-version/-m for all their site-packages installs. :) (Eventually, we can change this default, once the majority of packages declare their dependencies.)
As an aside, the thing that I'm trying to debug in A is a "Not a directory" error that I think is a __file__ usage.
You might try grepping for use of __file__ and __path__ in .py files; it's rare to touch either of those for any reason but data file access.