[Grok-dev] Grok 1.0a4 released!
Uli Fouquet
uli at gnufix.de
Fri May 22 04:10:53 EDT 2009
Hi there,
Jan-Wijbrand Kolman wrote:
> Tim Cook wrote:
> > Okay, so my sarcastic instructions didn't go over to well I guess.
>
> Well at least not by me, moments after doing a release.
>
>
> > It seems to me that the following is the best (only?) way to upgrade.
> > =====================================================================
> > (Assumes you already use virtualenv)
> > create a virtual environment for a new grok project:
> >
> > $ virtualenv --python=python2.5 --no-site-packages grok1.0a4
> > $ cd grok1.0a4
> > $ source bin/activate
> > $ easy_install grokproject
> > $ grokproject MyProject
> > $ cd MyProject
> > Now copy the new MyProject versions.cfg to your original project,
> > overwriting the current versions.cfg
>
> Right, now I understand the confusion; buildout.cfg files created by
> earlier versions of grokproject used to have an extends directive
> pointing to http://grok.zope.org/releaseinfo/grok-x.x.cfg.
>
> Merely updating the directive to point to the lastest release and
> running bin/buildout again would then have been enough for upgrade
> MyProject.
>
> But grokproject has changed; it downloads the versions file now instead.
> So yes, I guess your procedure is correct here.
Thanks to Tim and JW for bringing this up. And many thanks to JW for
doing the release! IIRC we introduced the local versions.cfg to better
support offline usage of `grokproject`.
It is in fact a plain copy of the latest .cfg file in
http://grok.zope.org/releaseinfo/ which could be found at the time of
running grokproject enriched by some recipe versions used during
buildout runs.
The ``extends`` directive should still work, I hope. So there are other
(minor troublesome) upgrading options available:
1) In the [buildout] section of buildout.cfg, _after_ the line saying::
versions = versions.cfg
insert::
extends = http://grok.zope.org/releaseinfo/grok-1.0a4.cfg
This way you override any versions in versions.cfg.
After rerunning bin/buildout you should be done. You might want
to update the [eggbasket] section as well, but this is in fact not
necessary to upgrade (but should speed up downloads/installations
on fresh installs with empty buildout eggs directories).
2) You could also replace the current versions.cfg with the latest::
$ wget http://grok.zope.org/releaseinfo/grok-1.0a4.cfg
$ cp grok-1.0a4.cfg versions.cfg
This way you lose the pinning of recipe versions used by buildout
(which you can find near the bottom of a fresh versions.cfg).
You can of course copy these versions over to your new versions.cfg.
3) If you do not care too much about offline usage, you can also just
use::
extends = http://grok.zope.org/releaseinfo/grok-1.0a4.cfg
and remove the versions.cfg directive in your buildout.cfg. The local
versions.cfg then might be deleted as well (to avoid confusion).
Goingh one of these ways you at least do not have to rerun grokproject
and can update your old projects with less copying and trouble.
In future We could also pin down the grokproject specific versions in
another file, so that copying over the current version file from
grok.zope.org should be sufficient. What do you think?
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/20090522/c74eab3a/attachment.bin
More information about the Grok-dev
mailing list