On Sep 25, 2007, at 9:53 AM, Tres Seaver wrote:

Hash: SHA1

Jim Fulton wrote:

* When package A depends on Y and package B also depends on Y,
but with some version restrictions, buidout will first try to get
the newest version of Y when installing A. But then when
installing B, it is likely that it has to get a different version
of Y. The result is a version conflict. This could also easily be
fixed with a working set that dictates which versions would be
used from the beginning.
IN the long run, this would be better served by a better algorithm
for constructing setuptools working sets.
... which would require having access to the dependency data before

No, not really, at least not in buildout's case.  It's really not
that big a deal to download a distribution that you ultimately don't

If we can keep setuptools from prematurely installing downloaded eggs,

I'm not sure what you are saying. I maintain that downloading eggs you don't use is not that big a deal. Avoiding this is just an optimization.

at the moment, it is trivial to get setuptools into a "false
conflict" situaltion, because it processes dependencies incrementally,
rather than solving the "transitive closure" of the graph before
attempting to install anything.

Sure, but this doesn't have anything to do with whether you download or not. It may be a consequence of the fact that setuptools tries to hard to figure out what to use without downloading enough. There is a similar problem with extras.

I agree it might be better if the index made dependency data

Not exposing the dependency information in the index seems like a
missing-feature-is-really-a-bug to me.

Likely. A problem is that there are 2 sigs when there really ought to be one. The distutils sig isn't demanding enough of the catalog- sig for changes to the index and the catalog-sig is somewhat grudglingly responsive. Some of this has to do with the fact that people who want catalog features really ought to help with implementation, but people who want the features don't have the time to learn the catalog app enough to enhance it. It would be nice if one of us was willing to become a catalog contributor so we could get some things done we need. Not it! :)


Jim Fulton
Zope Corporation

Zope-PAS mailing list

Reply via email to