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
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
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
BTW, since "working set" has a rather important meaning for
setuptools, I'd rather we find a different term for what you are
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 works fine as long as nothing changes. I think you'd be better
off keeping a grok kgs. But, again, I'll defer. :)
Zope-PAS mailing list