On Sep 25, 2007, at 8:13 AM, Philipp von Weitershausen wrote:

On 25 Sep 2007, at 14:06 , Jim Fulton wrote:
There are several problems.

* We've had to nail some of the versions because buildout was being a bit over-zealous when getting eggs on Windows. It would take the newest egg, despite the fact that other eggs had binary releases. I guess that's not its fault. But it's a working set problem.

It's probably a setuptools problem. It would probably make sense to give buildout a switch to prefer binary releases where they are available. (Perhaps the new prefer-final option would help here.)

Not when it has to chose between ZODB 3.8.0b2 and 3.9.0a1dev- r12345, of which are neither a final release.

We really need to get to final releases.

Right. We really need to shorten ZODB's release cycle, or stop making new releases. :)

* 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 installation.

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 use. I agree it might be better if the index made dependency data available.


BTW, since "working set" has a rather important meaning for setuptools, I'd rather we find a different term for what you are talking about.

Oh, you're right. Tres has used the term "known good set" in the past, I believe.

* Even with newest=false enabled in grokproject's buildout.cfg template, the versions that people will end up when trying out grok are non-deterministic. This has led to people installing newer versions of something, sometimes even faulty releases, even though Grok hadn't been tested with these newer versions yet and older versions that were known to work were the better choice. Again, a working set problem.

Right, but I don't understand how having one of these things for Zope 3 would help. After all, a new package that is tested and added to the 3.4 release might still not work well with Grok.

I see "known good sets" like the old tarball release, in the sense that we can say Grok 0.x works with Zope 3.y.z (for specific x, y, z).

I have a feeling that this won't be enough, but I'll defer. :)

Likewise, I'd like to be able to say that Grok 0.x is known to work well with a particular known good set of Zope. Modifying the known good set (by adding a newer version of a package, or by adding a new package altogether) would constitute a new version of the known good set which we'd have to try Grok out with before we give it our blessing. If we apply our release semantics (major/minor/bugfix versions) to known working sets (I think we should), then we might also loosen the nails a bit and say that as long as you stay within the bugfix versions of one known good set, you're fine. We've done this for releases in the past, I don't see why we can't keep doing this.

This works fine as long as nothing changes. I think you'd be better off keeping a grok kgs. But, again, I'll defer. :)


Jim Fulton
Zope Corporation

Zope-PAS mailing list

Reply via email to