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

[Uli Fouquet]

Hi there,

Jan-Wijbrand Kolman wrote:
> 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?

Here the problems start: grokui.admin is listed in Groks "KGS" _and_
added by grokproject currently. In the beginning it was only added by
grokproject.

With current grokproject/grok people get two version settings for
grokui.admin. This can happen again if new packages go into Grok or are
requested by grokproject.

We could avoid such a situation following Martijns proposal.

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

Unfortunately no, for the reason given above. We could, however, make
sure that only packages not listed in the retrieved Grok-KGS are added.

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

I think the grok versions.cfg is not the setup.py requirements listing.
It is, as you say yourself, kind of a Known-Good-Set list. So new
releases are not needed because of changed dependencies of grok itself,
but of its changed KGS.

One could, however, discuss only updating the KGS (and eggbasket) from
time to time.

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

We currently do that. grokproject fetches the Grok-KGS from
grok.zope.org and extends some packages. The result is written to a
generated versions.cfg. That led to the problems above.

We do, however, not use the 'extends' directive in buildout.cfg, because
that would require online-access each time you run buildout and we
wanted to avoid that.

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

I still think maintaining _one_ KGS (Groks version.cfg) and listing
'foreign' packages there is not a real dependency. There is still the
opportunity of only updating the KGS avoiding complete grok releases.

For now I will start by making sure, that grokproject only adds packages
not listed in Groks versions.cfg.

Best regards,

-- 
Uli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20090411/0417405c/attachment.bin