[Zope-dev] why external version indexes don't fulfill all use cases for development

[Jim Fulton]

On Nov 11, 2007, at 6:11 PM, Stephan Richter wrote:

> On Sunday 11 November 2007, Lennart Regebro wrote:
>> On Nov 11, 2007 8:06 AM, Martijn Faassen <faassen at startifact.com>  
>> wrote:
>>> I therefore still believe that version dependency information should
>>> move out of external indexes and into packages.
>>
>> This is at least the intuitive place for this information. My
>> application requires Grok 0.11, which requires zope 3.4.0b2 which  
>> then
>> would be a package that doesn't contain any code, just  
>> requirements of
>> eggs that in turn has requirements of their own. I'm not even sure
>> this *is* different from how the unices does it, but it just seems  
>> the
>> obvious way of doing it. I would be interested in knowing if this has
>> drawbacks.
>
> Meta-eggs are considered a bad idea in the Python world. I  
> originally wanted
> to create a meta-egg, but Jim convinced my to use a different  
> approach; hence
> the index.

Meta eggs aren't a bad or a good idea by themselves.  They are a good  
solution to some problems and a bad (or less good) solution to  
others.  IMO, meta eggs are a good way to fix versions in  
*applications*.  (I think buildout's version-specification mechanism  
is another good approach, with certain advantages and disadvantages).

I think a package repository, of which a KGS is an example, is a good  
way to provide access to a collection of packages known to work  
together -- especially as it provides a nice way to manage bug  
fixes.  I think "Zope 3"  is better served by a well-managed  
repository, because Zope 3 is a platform, not an application.   IMO,  
a well-managed KGS (set of KGS releases) will serve the community of  
developers who use Zope better than a rigid version specification.

Jim

--
Jim Fulton
Zope Corporation