[Grok-dev] Towards Grok 0.14
faassen at startifact.com
Wed Sep 17 06:46:58 EDT 2008
Leonardo Rochael Almeida wrote:
> May I suggest a tarball?
> Eggbasket is cool and all, but I think a Grok release should include a
> tarball. This could be just a buildout with built-in download cache
> that can be setup by running "python bootstrap.py; bin/buildout -No"
> (or, better yet, "python install.py"), and it should contain all
> dependencies not present in the python standard library for grok AND
> for grokproject.
> This buildout tar should build grokproject in its ./bin, and this
> grokproject should create buildouts based on the eggs already present
> on the tarball and configuring "newest=false" in buildout.cfg, so that
> downloading the tarball is the only operation needing network access
> before you can try out grok.
> Perhaps a tarball that creates a virtualenv instead of wrapping a
> grok/grokproject buildout would be easier, or maybe some other python
> package that creates tarballs out of buildouts, but the point is that
> installing Grok should never be more complicated or error prone than,
> to pick a completely random example out of my hat :-), Django.
Agreed, this is the ideal and we are clearly not there yet.
> Right now, even with eggbasket, we still need a number of things to be
> "Just Right On The Internet" for Grok to "Just Work" for someone,
> including a number of packages being on their right versions, as it
> seems like even version pinning is not sufficient to keep us safe from
> things that could break grokproject itself. I'd rather have the user
> just download one package beyond python itself to be able to get up
> and running with Grok.
Thanks for bringing this up, Leo; I think you're exactly right. The
comparison with Django is apt. We're solving a harder problem as Grok is
developed "in pieces" unlike Django, but that doesn't mean it shouldn't
be as easy to install as Django is.
Volunteers to work on this are welcome!
More information about the Grok-dev