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

[Uli Fouquet]

Hi,

Martijn Faassen wrote:

> Uli Fouquet wrote:
> [snip]
> >> 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).

If this is possible: very fine :-) I thought it was a bit too much to
release a new grok version only because a minor package, Grok even does
not depend on, changed.

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

Okay, very fine with me. I'd also prefer the more simple
one-file-gives-it-all approach for now. Here's the grokproject generated
list::

  # Here we pin the recipes and other packages that are not in the
  # downloaded versions.cfg of grok
  grokui.admin = 0.3.2
  Paste = 1.7.2
  PasteDeploy = 1.3.2
  PasteScript = 1.7.3
  setuptools = 0.6c9
  z3c.evalexception = 2.0
  z3c.recipe.eggbasket = 0.4.1
  z3c.recipe.i18n = 0.5.0
  z3c.recipe.template = 0.1
  zc.buildout = 1.1.1
  zc.recipe.egg = 1.1.0
  zc.recipe.filestorage = 1.0.1
  grokcore.startup = 0.2

At least grokui.admin and grokcore.startup should vanish there then,
right? We need another grok release then, that includes grokcore.startup
before next grokproject is released. What about Paste, setuptools and
zc.buildout? I'd tend to move also Paste-related packages, still unsure
about setuptools, zc.buildout and the recipes.

Well, it's the right time to move all those eggs ;)

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/24024c1a/attachment.bin