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.
* 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.
Nevertheless, we need something in the short run.
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).
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.
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
