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.:
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.
> - 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::
extends = http://download.zope.org/zope3.4/versions-3.4.0.cfg
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -