I think I've found a bug in the way that setuptools selects whether an egg
specified by file:// url should be installed over an existing (identical) egg:
To re-create the fault:
* Install the egg of your choice.
* make two local "egg repositories", one with a very long path (e.g. c:/a/) and
one with a very long path
* In each of the egg repositories place a copy of the egg you just installed,
along with an HTML file containing a link to that egg... just it's filename.
* Try to easy_install the egg with the options "-mv" and set "-f" to either one
of the repositories
When you select a short path for the repository you will notice that the egg in
your site_packages folder is always replaced, you see something like this:
"Removing
d:\devtools\python24\lib\site-packages\calyon-1.0_r2009_03_12-py2.4-win32.egg"
When you select a very long path for the repository you will not see this
message, this is because easy_install leaves the egg unmodified.
I've found out why this happens: The pkg_resources.Environment uses a hash-tuple
to work out the order in which to consider packages to install. If you are
trying to install two identical eggs, the 4th element of the tuple
-len(self.location or '') becomes significant... longer URLs get preference to
shorter URLs.
That on it's own might not seem too bad, but consider the the 2nd value of the
hash-tuple (precedence) is given an identical value of 3 both for a package
which is already installed in pkg_resources and a package which can already be
downloaded from a file:// link. I think a better default behaviour would be for
it to give stuff that is already installed a higher precedence than stuff which
could potentially be installed.
|