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

[Jan-Wijbrand Kolman]

Martijn Faassen wrote:
> 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.

We're only talking about packages here that Grok's versions.cfg does not
list, right?

If that's the case than I do not see a problem with grokproject creating
a versions.cfg for you new project, extending from a grok-1.0a3.cfg (for
example) that was downloaded and put in this new project as well.

The versions.cfg that grokproject created then only lists the packages
that are not listed in Grok's "kgs".

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

I would not agree with this aproach; I think it would be strange for a
package A - with no dependencies on B and C - to need a new release
because B needs a newer version of C...

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

Why? Why can't the newly created project not just have a versions.cfg
extending from Grok's versions and list its extra dependencies there?
That's what buildout's extend directive is for, right?

> 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)

So, basically, practically, grok starts to depend again on (the
lifecycle) of grokcore.admin? Maybe we should conclude grokcore.admin
indeed is a direct dependency of grok after all.


regards,
jw