[Grok-dev] grokui.admin referenced twice in generated versions.cfg

Martijn Faassen faassen at startifact.com
Fri Apr 10 14:57:41 EDT 2009


Uli Fouquet wrote:
>> At first glance I'd prefer a simpler approach of simply updating a file 
>> somewhere compared to adding a snippet.
> You mean some URL, like grok.zope.org/releaseinfo/... ?

Yes. Or creating a new such URL by making a new Grok release.

>> That way it's easy to reason 
>> about your versions.cfg - it's going to be the same as the one in the 
>> URL, unless you change something. What would be the advantage of 
>> grokproject doing this?
> grokproject indeed fetches the latest versions.cfg from grok.zope.org.
> But it adds some stuff not needed with stock grok or only with special
> grok instances, the eggbasket recipe version for instance, or the paster
> eggs. This makes grokproject more independent from Grok releases,
> because you do not have to wait for a new Grok (and accompanied
> versions.cfg) if you want a new eggbasket recipe to be used. Beside
> this, I fully agree.

I don't think it's right for grokproject to defer to versions.cfg except 
for *some* stuff where it suddenly decides on versions itself baked into 
the grokproject release.

So either we maintain this version in the master versions.cfg (and just 
release a new version of Grok when we want people to move onto a new 
version of grokui.admin).

Alternatively we come up with some concept of an extra set of versions 
that can be maintained independently that just contains the versions for 
grokui.admin, or megrok.whatever, etc. grokproject would then combine 
multiple such lists into a single list somehow. I think that an 
infrastructure for this is needed eventually, as any library built on 
Grok (not just grokui.admin) has similar issues if it is composed out of 
multiple packages. But perhaps for simplicity's sake for now we should 
stick to Grok releases and Grok's versions.cfg.

So, for now, I'd suggest when we do a new grok release we simply update 
the grokui.admin version in it if necessary. And if there are big 
changes in grokui.admin we everybody to see, we make a new Grok release. 
(instead of a new grokproject release)

Recipes have a bit of a special status - this varies during installation 
time, not run-time. I never quite figured out what the right thing is to 
do for those. :)



More information about the Grok-dev mailing list