Leonardo Rochael Almeida wrote:
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).
Thank you for the pointer, I'll look into it. Fixing this along with other download-related things before the next buildout release would be a good thing, I think.
- "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.
Sure, I meant the section name to read "checksums" but a typo crept in.
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:
This would be ugly in my humble opinion because it reverses the meaning of keys and values and makes the configuration look backwards for a purely technical reason. Also, the following:
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
becomes even worse when you want to update a checksum specified in a configuration file that is being extended: you'd have to keep track of two checksums for each resource, once to invalidate the old one and once to specify the new one.
Thank you for your input, though!