On Friday 09 November 2007, Tres Seaver wrote:
A KGS needs to have the following properties:
- The "generation zero" of any KGS is an empty set of revisions.
Yes, luckily we are far beyond that point.
- 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.
Yes, I have to ask Jim to create a "zope-dev" directory for me that will function as the draft KGS.
- Once "finalized" / "published", a given revision of a KGS can *never* be changed.
I think this can be easily accomplished by released versioned versions.cfg files. Starting with the next release I will create these files; they will have the form "versions-x.x.x.cfg", for example "versions-3.4.0b3.cfg". Overall, I originally did not see the use case for totally fixing the versions. But you and Lennart got me convinced. In order to safely deploy an application, you need to fully fix the versions, just to be very sure. So I think the revised workflow looks like this: 1. During development, you depend on the latest stable KGS, using the index option in buildout. This way you get the latest bug-fix releases, but you are *not* interupted by major feature changes. This would be the same as working with a Zope3 release branch before. Of course, if you are brave, you can also develop against the "zope-dev" KGS, which can be compared to working with Zope3 trunk before. 2. Once you you are ready to deploy your application, you can choose a specific versions-*.cfg or even download the latest KGS configuration in versions.cfg (which is more risky, since you might an uncommon set).
- 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.
I think this could be easily accomplished by writing a little bit more software. I think the best syntax would be as follows -- i.e.: grok-controlled-packages.cfg:: [KGS] bases = http://download.zope.org/zope3.4/controlled-packages.cfg I think adding this functionality would be straight forward. I guess with urllib2, the protocol could be almost anything.
- 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.
Why do you need find-links in the mix? It must be a policy, that any published release can *never* be revoked.
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.
Why would I need to create a PyPI index, if I want to fix all versions? It is much easier to reference "http://download.zope.org/zope3.4/versions-3.4.0.cfg" (for example) in your buildout file:: [buildout] extends = http://download.zope.org/zope3.4/versions-3.4.0.cfg Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training