[Grok-dev] a grok installer download Was: Re: remove the download tarball functionality from grokproject?

[Roger Erens]

Hi Martijn,

> One drawback of the default.cfg is that it is global. It's essential if we
> don't want people to download their eggs over and over again, but it's also
> interfering with any and all buildouts. Normally that's all right, but I've
> had a complaint from Chris McDonough a while back that it screwed up
> repoze.bfg installs.

IIRC, there's also this possibility: a user who wants to install Grok
is already using a default.cfg, in which the path to the Python
interpreter is set to one that Grok doesn't like currently, e.g.

executable = /usr/local/python/2.4/bin/python
or to an incompatible interpreter
executabe = /usr/local/python/3.1/bin/python

Probably such a setting should be overridden in buildout.cfg using the
python option of zc.recipe.egg?
I'm not sure, even after reading some of the info at
http://www.buildout.org/docs and browsing a little bit through the
zc.recipe.egg's info...


Something else: would it be beneficial to have this omelette part also
by default in Grok's buildout.cfg? Kevin suggested it to the Django
people:

[omelette]
recipe = collective.recipe.omelette
eggs = ${buildout:eggs}

>
...

>
> P.S. For future reference I've attached my experimental grokinstaller
> buildout.cfg. To create project 'foo', use "bin/grokproject
> --eggs-dir=/wherever/i/unpacked/grokinstaller/eggs foo". But this will
> create a hardcoded 'eggs-directory' in the generated buildout.cfg, which is
> wrong. We need to do the default.cfg dance instead.

Could the option
relative-paths = true
in zc.recipe.egg be of any use?

Regards,

Roger