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! -- Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
