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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> 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.

Doing only that would be like having a release branch but no tags, i.e.,
unacceptable.  Creating "frozen snapshots" (like CVS/SVN) tags after
adding and testing new versions shouldn't be any harder than making a
tag is today.

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

If we have software which can generate the pacakge index at a URL for a
KGS, then it could certainly generate a 'version.cfg' as well, to
support buildout.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNazm+gerLs4ltQ4RAswyAKDaSgJSIw32gckbd9ctLUX+tgt6GQCbB9ON
pYBf589Zdj/0aSihzXfzMvY=
=RlBH
-----END PGP SIGNATURE-----