[Zope-dev] Re: pinning, nailing and kgs'ing

[Martijn Faassen]

Hey,

Kevin Teague wrote:
> And it would also be really nice 
> if the Grok terminology and release methods lined up with the Zope 3 
> terminology and release methods :)

Grok got there first, then KGS came along and did a lot of stuff. The 
reason Grok's story is not the same as the one in KGS is that we haven't 
caught up with the new stuff yet. We of course reserve the right to 
simplify it for our purposes. :)  What seems most useful about KGS is 
that it tests versions of eggs together and publishes a list of those 
versions that are known to work together.

The Grok process is fairly simple:

* when we release grok, we also release a versions.cfg on 
grok.zope.org/releaseinfo. We name it after the new release of Grok, and 
don't ever change it anymore.

* we also update a special URL that grokproject makes use of to 
determine the last release of Grok. This way a newly created grokproject 
automatically gets configured to use the right releaseinfo URL

* grokproject then pins those versions in buildout.cfg using the 
'versions = versions' and 'extends = 
http://grok.zope.org/releaseinfo/some-release-versions.cfg' lines in 
[buildout].

We don't have any special index servers or anything. Right now we point 
to PyPI and download.zope.org/distribution; the latter will likely 
eventually go away as all eggs are properly on the cheeseshop.

We do have some issues concerning development, which I think you ran 
into by looking at the viewlet branch. We can probably simplify the 
branch by now as we did release a new version of Martian that has the 
required changes.

We intend to try to go with KGS's list of packages. We need to test that 
and determine the best way to reuse that list. I don't think we'll do 
much else for now - Grok's process works fairly well for us.

One thing that we should eventually improve is to allow grokproject and 
Grok buildouts to work offline. Right now buildout.cfg refers to a URL 
in the 'extends' line which breaks things. Another thing I'd like us to 
experiment with is to offer a one-tarball download of Grok, possibly in 
combination with a frozen repository which contains all Grok 
dependencies for a particular release. On the longer term I am still 
curious about experimenting with getting the "these versions of my 
dependencies are tested to work" information into the eggs themselves 
somehow.

Regards,

Martijn