[Grok-dev] Towards Grok 0.14

Martijn Faassen faassen at startifact.com
Wed Sep 17 14:11:08 EDT 2008


Peter Bengtsson wrote:
> 2008/9/17 Leonardo Rochael Almeida <leorochael at gmail.com>:
>> 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.
>>
> 
> -1
> I disagree because it causes confusion. Basic usability 101. Grok
> isn't monolithic. Pylons and their installation docs[1]  look pretty
> similar to those of Grok[2].

I suspect Pylons installs completely through easy_install though. I 
cannot find anything that's the equivalent of grokproject.

Leo's idea is very close to the toolset we already use. Instead of 
telling people to easy_install grokproject, we tell people to download a 
tarball. Then running an installation script there, it'll set up 
grokproject and install all the eggs (which are also in the tarball). 
Afterwards 'grokproject' works as before, though you may need to start 
it from this special directory: install/location/bin/grokproject

We could make the eggs directory also be in that directory, instead of 
in .buildout/eggs, though this can be debated.

The idea of a tarball is that we limit the amount of "Things that can go 
wrong on the internet" to the first download of the tarball. Thereafter 
everything should just be local.

Right now we still have multiple accesses to the web by multiple tools:

* easy_install: grokproject

* grokproject: access current grok version

* grokproject: download versions list

* eggbasket recipe: download eggbasket tarball

* buildout/setuptools: download any eggs that weren't in the eggbasket (bug)

There's quite a bit that can go wrong with that still. Different tools 
can fail in different ways.

We could limit this to:

* download tarball which contains install script, grokproject, all 
required Python packages, versions list

The idea is 1 access to the web. The nice thing also is that this can be 
done through a web browser, making it more likely that things will 
succeed (firewalls and such).

Of course we can still make the same mistake as above, in that we can 
forget to put certain essential bits in our tarball. This would trigger 
accesses to PyPI by buildout.

Of course once you have your grok project up and running you'd need to 
do PyPI accesses again to install any extensions, but it'd still be less 
failure prone than the multi-stage process we have now.

Regards,

Martijn



More information about the Grok-dev mailing list