[Zope-PAS] Re: Eggification redux

[Jim Fulton]

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

--
Jim Fulton
Zope Corporation