Sebastien Douche firstname.lastname@example.org schrieb:
I've been implementing a download API for buildout and have reached the point where I'd like to try using it for downloading the base config files referenced from a buildout config by the 'extends' option. This would have the benefit of allowing to cache those config files and being able to run a buildout using that feature while being offline.
Do you talk about index and find-links too? And for the bootstrap? I search a scenario to deploy a buildout fully offline.
Those would be useful indeed. However, afaics the respective code doesn't have access to the zc.buildout package (easy-install downloads use setuptools and at bootstrap time, zc.buildout hasn't even been downloaded yet).
Right. You think about "offline" option or "install-from-cache" option? offline seems to be a good candidate.
I've implemented three ways of handling the cache:
- don't use it at all, fail if offline mode is on or the resource cannot be accessed
- use a cached copy of a file unconditionally if one is found in the cache
- try to download a resource if not in offline mode, only fall back to using the cache if this fails
I was talking about using the third option when fetching configuration. Other client code (i.e. recipes) may choose freely how to use the cache and whether to make that decision based on a configuration option.
Hmm, just an idea on the same area: caching only some packages (not only "all" or "none"). Surely out of your scope...
This is out of the scope of zc.buildout's core IMO. A particular recipe might implement any algorithm to decide how to use the cache when downloading one package or another. I even think this would be too complex for a core recipe such as zc.recipe.egg.