[Grok-dev] Re: AW: Re: Grok 0.11 released!
tseaver at palladion.com
Sat Nov 10 08:06:46 EST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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.
>> - 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
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
-----END PGP SIGNATURE-----
More information about the Grok-dev