[Zope-CMF] Re: [Zope-PAS] Re: Eggification redux

[Philipp von Weitershausen]

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.