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

Philipp von Weitershausen philipp at weitershausen.de
Sat Nov 10 04:02:29 EST 2007


Tres Seaver wrote:
> A KGS needs to have the following properties:
> 
>  - The "generation zero" of any KGS is an empty set of revisions.
> 
>  - 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.
> 
>  - Once "finalized" / "published", a given revision of a KGS can
>    *never* be changed.

I sympathize with this thinking, but as far as I understood Jim and 
Stephan last night, there seems to be the goal to make a KGS for a whole 
stable release branch, e.g. "Zope3.4", and keep on adding bugfix 
releases. So there doesn't seem to be a consensus yet on how we should 
manage KGSs.

>  - 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.
> 
>  - 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.

That makes more sense to me than the locked down index.

> 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.

Right, I suppose that can be arranged on top of the version.cfg thing. I 
find the locked down index approach attractive because it works with 
pure setuptools, and it largely takes the responsibility out of Joe 
Middleclass Developer's hands. That is also its greatest weaknesses 
because doing anything that's not in the KGS requires some situps, for 
instance managing a find-links location with the extra packages you want 
to install. The locked down index is also exclusive, two orthogonal KGSs 
are best merged using the version.cfg approach, it seems.


More information about the Grok-dev mailing list