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.


 - 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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to