[Grok-dev] Re: AW: Re: Grok 0.11 released!
tseaver at palladion.com
Fri Nov 9 23:12:31 EST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Martijn Faassen wrote:
> Roger Ineichen wrote:
>> Hi Tres
>>> Whoever released those two eggs (the '.dev-r#####' ones) need
>>> to release "real" updated packages, and then grok 0.11.1
>>> should be released using them.
>>> DEATH TO FAUX PACKAGES!
>> As far as I understand, this does not happen if you
>> depend on a KGS, right?
>> Does the grok release not use the KGS from Stephan?
> Not yet. We intend to look at that list at some point. Of course the KGS
> probably doesn't contain recent enough packages to support the REST
If the REST stuff depended on unreleased versions of upstream packages,
then it should not have been merged until those packages were released
in an acceptable (non-snapshot) form.
> The other problem with KGS is that I absolutely want to fix lists of
> packages into Grok itself and never rely on any system that can cause
> the list of packages that could be updated. KGS will get bugfix
> releases. These will inevitably break something on occassion. I have no
> idea what will happen once 3.5 packages will start to appear, either.
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.
- 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.
- 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.
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