Open FallenChromium opened 2 months ago
Hi @FallenChromium
You can try passing -DCONAN_INSTALL_ARGS="--no-remote"
for subsequent installs - this should stop checking for subsequent calls.
I think it depends on what part of the install process is actually reaching out to the remote - I suspect it is the compatibility extension, which can be tweaked to satisfy your needs as well.
To be honest I haven't found a way to set it up so that Conan will use remotes on the first configure call but will not do so on reconfigure, unless conanfile.py has been changed. Maybe you have some ideas on how to implement it? Do you think this should be done by default on conan_provider.cmake?
Hello! I'm currently experimenting with Conan in our open-source project to streamline the cross-compilation process. I've copied conan_provider.cmake from this repo and injected it using TOP_LEVEL_INCLUDES variable inside some of the presets I've defined in "CMakePresets.json" file.
The problem I've encountered is that the configuration step in my IDE is called on a regular basis, and it fails regularly if my connection times out to ConanCenter. This is undesired since "conan install" was already fired up upon first configuration and resolving dependencies from cache should suffice. The error log has a recommendation to use the no-remote flag, but I recognize that it will lead to inconsistencies if I'll add it to conan_provider.
How can we set up a fallback so that the CMake configuration wouldn't fail if all dependencies are present in the cache but Conan can't contact the ConanCenter? I think this is the intended behaviour since pinging ConanCenter on every reconfig (even if the project was already configured with the same preset) sounds like infrastructure expenses to me