[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