[feature] Add option to clean the cache before update via `config_install_interval`

[gpxricky]

What is your suggestion?

Hi,

I really like the possibility to update the Conan configuration periodically via the config_install_interval variable. However, this doesn't fit our needs to 100%. It would be great if the automatic update functionality could be enhanced to clean the cache (not the package data, but the profiles and hooks) before the configurations are updated. E.g. via a config_install_clean variable in the conan.conf file. Unfortunately this isn't that easy:

• What shall happen if the configuration is not reachable (e.g. no internet access, folder has been removed, etc.)? Is the cache cleaned but the configuration not applied then?
• Which kind of data shall be cleaned (profiles, hooks, etc.) and which kind of information shall be kept (data folder, ...)?

Another solution would be to provide a hook for that purpose, so a project specific clean up is possible:

from conans import tools

def pre_update_config(cache_dir, configs, **kwargs):
    # Project specific clean up of the cache (config provides access to config_install.json structure)
    pass

def post_update_config(cache_dir, valid_configs, invalid_configs, **kwargs):
    # Project specific stuff (valid_configs points to all configs in config_install.json that have been updated properly)
    # Does this make sense if the file has been replaced during the update?
    pass

What do you think?

Best regards, Markus

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @gpxricky

Thanks very much for your suggestion. However I don't think that this will be possible. We have actually removed in Conan 2.0 the whole config_install_interval feature. It was too problematic and complicated.

A different thing might be if we decouple the feature from the automatic config install. Does a conan config clean command that restores the Conan home to the initial state make sense? Basically a conan config clean + conan config install url achieves the goal? That might be doable.

[gpxricky]

Hi @memsharded

actually I just wanted to open another issue that it is quite impossible now (with enabled config_install_interval functionality) to capture STDOUT of Conan as it may be flooded from time to time with messages from the interval update. Therefore a simple conan remote list is now complicated to parse :-(.

I can imagine that there is lot of other trouble (failing updates, etc.) that makes it even more complicated. Therefore removing the functionality makes sense and is fine for me. I will try to find another way to realize a Conan 2.0 compatible auto-update. The conan config clean may be helpful, but it depends on the meaning of the initial state. E.g. in case it is equal to a non-configured cache (except the storage folder) it is fine for my use case. If it is more or less a conan config init then it does not fit my needs.

[memsharded]

actually I just wanted to open another issue that it is quite impossible now (with enabled config_install_interval functionality) to capture STDOUT of Conan as it may be flooded from time to time with messages from the interval update. Therefore a simple conan remote list is now complicated to parse :-(.

This has completely changed already in Conan 2.0. All the output goes to stderr, except the really important bits, that goes to stdout. All commands that expect something valuable will also have a --format argument to output json or other formats that is easier to parse, it will be explicitly documented in the docs that the terminal output will not be stable and not intended to be parsed, anything intended to be read by machines should be a --format one.

I will try to find another way to realize a Conan 2.0 compatible auto-update.

This sounds to us something more system-level thing, like a cron job or similar thing.

The conan config clean may be helpful, but it depends on the meaning of the initial state. E.g. in case it is equal to a non-configured cache (except the storage folder) it is fine for my use case. If it is more or less a conan config init then it does not fit my needs.

Yes, that would be the idea. To completely remove all config and reset it to the original state after a clean Conan install (except the packages storage).

[gpxricky]

Hi @memsharded,

actually using a cron job or scheduled task is the way I will go for.

Yes, that would be the idea. To completely remove all config and reset it to the original state after a clean Conan install (except the packages storage).

This sounds great and would be a good idea then.