Hi Thomas,
I like your idea in general. I'd like to point to the following suggestion with patch+test (though it might need some cleanup) that is not exactly related to what you're proposing, but has to do with the same thing (relationship between files and checksums):
https://bugs.launchpad.net/zc.buildout/+bug/692600
It suggests (and implements) automatically redownloading files when checksums don't match (which could happen when you update your config file with a new checksum for a file that has changed upstream).
Other comments below:
On Thu, Mar 17, 2011 at 16:55, Thomas Lotze thomas@thomas-lotze.de wrote:
Hi,
[...]
- "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.
Won't 'checksums' (plural) as the value be better? It would keep with the tradition of matching the name of the buildout option and the name of the section by default.
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.
I suggest mapping the checksums (which are valid keys) to URLs, and having a special key with line-break separated values for explicitly not checking:
[checksums] 080d2c6a849ebd6b7fd49049c21b910a = http://example.com/foo/bar.tgz no-check = http://example.com/foo/baz.tgz http://example.com/foo/fred.tgz
This will not be so elegant when you want to extend another configuration and override some decisions, but it works somewhat:
[buildout] extends = config-file-above.cfg
[checksums] 080d2c6a849ebd6b7fd49049c21b910a = no-check += http://example.com/foo/bar.tgz
[...]
Cheers, Leo