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.
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
