Thomas Lotze wrote:
In analogy with version pinning for eggs, two new options could be introduced to the buildout section:
- "checksums": This option would name a config section that contains checksums for any number of resources by URL. I suggest a default value of "checksum" for it. Listing some URL with an empty checksum would explicitly express that the checksum for this resource should never be checked. I'm not sure how to structure the contents of the checksums section: URLs are not valid config keys in general (they can contain "=" characters) but I'd still like to be able to rely on the existing mechanism for overriding single options to override single checksums. Mapping arbitrary keys to whitespace-separated pairs of URL and checksum would work but sounds inelegant.
OTOH, thinking further about a line format like "name = url md5sum", I find more advantages than just the fact that it would be syntactically valid: Recipes such as zc.recipe.cmmi or gocept.download could reference the resource name instead of the url, and in analogy to zc.recipe.egg, they might even infer the resource name from the section name:
[checksums] foo = http://example.org/foo.tgz 96772abbcb3331f63d05ffba40b7b523 bar = http://example.org/bar.tgz 64d714a998cab0c45c48307698317a0f baz = http://example.org/baz.tgz 22bfb8c1dd94b5f3813a2b25da67463f
[install-foo-by-url] recipe = zc.recipe.cmmi url = http://example.org/foo.tgz
[install-bar-by-name] recipe = zc.recipe.cmmi source = bar
[baz] recipe = zc.recipe.cmmi
It's possibly worth some amount of bike-shedding what the concept of the resource should really be called: For a cmmi recipe, "source" seems to work best as a key while a more general download recipe might indeed use the word "resource", and there's also the question of whether and how to reference extended configuration files by resource name. But my first question is whether this whole idea makes sense to other people at all or whether it adds more abstraction than it is worth.