[Grok-dev] Re: [Zope-dev] Re: AW: Re: Grok 0.11 released!

[Stephan Richter]

On Friday 09 November 2007, Tres Seaver wrote:
> A KGS needs to have the following properties:
>
>  - The "generation zero" of any KGS is an empty set of revisions.

Yes, luckily we are far beyond that point.

>  - By default, any revision N of a KGS starts out as a "draft" version
>    which is an empty layer over version N-1.  Changes to the draft
>    then shadow any versions in the prior revision.

Yes, I have to ask Jim to create a "zope-dev" directory for me that will 
function as the draft KGS.

>  - Once "finalized" / "published", a given revision of a KGS can
>    *never* be changed.

I think this can be easily accomplished by released versioned versions.cfg 
files. Starting with the next release I will create these files; they will 
have the form "versions-x.x.x.cfg", for example "versions-3.4.0b3.cfg".

Overall, I originally did not see the use case for totally fixing the 
versions. But you and Lennart got me convinced. In order to safely deploy an 
application, you need to fully fix the versions, just to be very sure. So I 
think the revised workflow looks like this:

1. During development, you depend on the latest stable KGS, using the index 
option in buildout. This way you get the latest bug-fix releases, but you are 
*not* interupted by major feature changes. This would be the same as working 
with a Zope3 release branch before. Of course, if you are brave, you can also 
develop against the "zope-dev" KGS, which can be compared to working with 
Zope3 trunk before.

2. Once you you are ready to deploy your application, you can choose a 
specific versions-*.cfg or even download the latest KGS configuration in 
versions.cfg (which is more risky, since you might an uncommon set).

>  - Any KGS can be derived from the published version of another KGS,
>    with additions of new distributions / versions and updates of
>    versions for underlying distributions.

I think this could be easily accomplished by writing a little bit more 
software. I think the best syntax would be as follows -- i.e.: 
grok-controlled-packages.cfg::

  [KGS]
  bases = http://download.zope.org/zope3.4/controlled-packages.cfg

I think adding this functionality would be straight forward. I guess with 
urllib2, the protocol could be almost anything.

>  - In conjunction with a "find-links" site which promises never to
>    remove any distribution which has been included in a published
>    revision of a KGS, the current 'version.cfg' (and workalike)
>    files are sufficient to establish a KGS.  Without that promise,
>    however, those files can't be considered as defining a KGS.

Why do you need find-links in the mix? It must be a policy, that any published 
release can *never* be revoked. 

> Therefore,
>
>  - Given that all distribution versions mentioned in a KGS are
>    stored at a trusted / reliable URL, any immutable KGS revision
>    can be trivially transformed into a PyPI package index: each
>    distribution will have exactly one allowed version, which will
>    point to a single URL on a reliable server.

Why would I need to create a PyPI index, if I want to fix all versions? It is 
much easier to 
reference "http://download.zope.org/zope3.4/versions-3.4.0.cfg" (for example) 
in your buildout file::

  [buildout]
  extends = http://download.zope.org/zope3.4/versions-3.4.0.cfg

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training