We are performing a version check in our organization to ensure everyone is kept up to date on the latest version of Conan (based on our own validation of that version). We are doing this through a custom hook that checks the current Conan version once a day. Currently we can only perform that version check at the package level because hooks currently only work at this level. This means we must rely on certain triggers, like the downloading of a package in order to execute our hook.
A more global hook would be extremely helpful to keep for us and might have other use cases for us in the future. This hook could be "global()" or "pre_conan()" and execute any time a Conan command is issued.
@memsharded Should such hook be put into the API wrapping since the hook_manager is created there? The problem though is that the API is pretty granular and there could be multiple calls from a single command, so you can't reliably put it in there.
It'd be good to also maybe set a command name as a parameter, but the API seems to be a bit messy since it differs from the command line interface quite a lot.
The problem though is that the API is pretty granular and there could be multiple calls from a single command, so you can't reliably put it in there.
Not really, there is a 1-to-1 relationship between commands and conan_api calls. Most precisely, every command in command.py will call exactly 1 conan_api call. So probably yes, the conan_api is a good place to put such init (name to be defined) hook.
The conan_api aims to be a programmatic extension of the command line, using different methods when different types or inputs are involved, for example search_recipes or search_packages for the conan search command, based on the input.
@memsharded That's not always the case, for example:
https://github.com/conan-io/conan/blob/develop/conans/client/command.py#L1297
https://github.com/conan-io/conan/blob/develop/conans/client/command.py#L1302
You have two API calls per command, which may be a bit unintuitive for the hook to spawn twice.
Yes, but that is the exception, it is marked with a comment, will remove that when possible:
Deprecate 2.0: Dirty check if search is done for all remotes or for remote "all"
In any case, a hook that operates on every conan invocation (e.g. to call conan-config-install) should have a time check, a counter or something, because otherwise it would be too heavy to be called every single time. So I think we shouldn't design with this exception in mind, and a hook for every api called could be fine.
I've made a basic implementation: https://github.com/conan-io/conan/pull/6434
Please see the discussion points to build upon.
Most helpful comment
I've made a basic implementation: https://github.com/conan-io/conan/pull/6434
Please see the discussion points to build upon.