[Zope-PAS] Re: Eggification redux

[Jim Fulton]

On Sep 25, 2007, at 7:55 AM, Philipp von Weitershausen wrote:

> On 25 Sep 2007, at 13:20 , Jim Fulton wrote:
>> On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote:
>>
>>> Charlie Clark wrote:
>>>> Am 25.09.2007 um 02:05 schrieb Tres Seaver:
>>>>> I'd like to break the remaining CMF packages out (moving from '/ 
>>>>> CMF' to
>>>>> 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the  
>>>>> 2.1.0 eggs
>>>>> out, as well as equivalent changes for PluggableAuthService and
>>>>> PluginRegistry.
>>>>>
>>>>> Any objections, or other thoughts?
>>>> While I am very sceptical about the move to eggs (I know it's  
>>>> inevitable) and I hope we can avoid some of the problems that  
>>>> seem to be affecting Grok as a result.
>>>
>>> Grok's problems are primarily related to the lack of a working  
>>> set definition for Zope 3.
>>
>> I don't know what you mean by this.
>
> 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.)

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

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.

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

Jim

--
Jim Fulton
Zope Corporation