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

[Jan-Wijbrand Kolman]

On Sat, Apr 11, 2009 at 11:31 AM, Uli Fouquet <uli at gnufix.de> wrote:
> 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.

If these two settings are listed in one file (versions.cfg as
generated by grokproject) then yes, that's problematic. I would find
it a lot less problematic thoughj if grokproject would generate a
versions.cfg, *extending* from grok's KGS and only listing where it
want to amend or deviate. That fully using the flexibility that the
KGS actually pursues.

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

Exactly my point; I find it strange to release grok, because some
other package now requires a newer version of yet another package.

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

I think so yes, see also my remark at the end.

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

You would not have that problem if you would *download*
grok-1.0a3.cfg, put this file the new new project, create a
versions.cfg extending from it containing onlypackages or versions of
packages where it wants to deviate. No net access on subsequent
buildouts (for the extend directive at least) *and* a clear seperation
between what KGS is in use for that project and where that project
differs from it.

> I still think maintaining _one_ KGS (Groks version.cfg) and listing
> 'foreign' packages there is not a real dependency.

I think it is practically speaking, if it means having to *release* grok for it

> There is still the
> opportunity of only updating the KGS avoiding complete grok releases.

How could we do that right now? But yes, maybe we can indeed resolve
all of this if we too seperate the KGS (for Grok) from grok itself. I
think I actually may have slightly misinterpreted Martijn's
suggestion; he suggested to keep things simple *for now* and to solve
this situation for the time being with grok releases, and then - I
guess - later on to work out the proper infrastructure for this.
Right? That's an aproach I can certainly live with.. :-)

regards,
jw