[question] Documentation for `core.download:download_cache` about docs HOT 4 OPEN

Thanks for the feedback. I am re-opening and moving to the docs repo, this would still be nice to document better.

from docs.

Finally (unrelated to this) what is the best way of programatically applying a core.* config value?

Just to clarify this a bit: we'd like to apply different core.* configurations on different machines. In this case, to enable the download cache for CI machines but not on developer machines.

from docs.

Hi @PeteAudinate

You are right, there is some documentation pending for this feature.

My understanding is that it can be used on a CI node to prevent the need to repeatedly download dependencies from a Conan remote every time a job is run. Is it suitable for this use case?

Yes, this is the use case, trade local storage for network transfer. In practice for fast networks it is not a huge saving, because artifacts are kept as-is, so it is still necessary to unzip them, and that is the most expensive operation. But it will certainly save bandwidth in any case

More specifically, are there concurrency guarantees? For example, is safe to use even if multiple executors are running simultaneously on the same machine?

Yes, the download cache is designed to be concurrent, at the machine level (lock-synchronization use file system locks, which is an OS-level mechanism), so it might not work for network or shared drives across different machines, specially different OSs, but it should be able to use it from multiple concurrent Conan caches in the same machine.

Finally (unrelated to this) what is the best way of programatically applying a core.* config value? Conan v1 had conan config set. It looks like core config can't be overridden with profiles or commandline parameters. Does this mean the only way is something like echo "core.foo=bar" >> .conan2/global.conf, or is there a better way?

There are no global.conf edition commands in 2.0, because the file is a jinja template and it is not possible to round-trip it.
But it should be doable to add some conditional on jinja to enable the conf only for specific machines, based for example in some environment variable. You can always have another different global.conf and conan config install that file only from CI. Note the conan config install can be used for multiple origins, to install individual folders, etc.

from docs.

Many thanks @memsharded for your quick reply, exactly what I was hoping to hear! Much appreciated.

I'd considered the extra conan config install, though then we'd have multiple global.conf files that need keeping in sync. The templating option sounds promising though, thanks for the tip.

from docs.