it's pretty annoying that conan-center hook reports not only errors/warnings for the package being built/tested, but for all of its dependencies. they are obviously useless and uninteresting for the contributor.
it's mainly for the post_package_info hook right now, as other methods besides package_info (export, source, build, package) are only executed for the package being built/tested.
from the signature of the hook, there is no easy way to say if current conanfile/reference is the main one, or dependency:
there is nothing interesting in public ConanFile fields as well.
to complicate things, it seems like the hooks object is being re-created each time, so it's not trivial to save any state between method invocations, it's always brand new, constructed from scratch.
the reliable process-wide storage is sys.modules, which works well, regardless of how many times python file is loaded.
it's a bit complicated, as we don't invoke conan create in CI, we do conan install --build=<package> and then conan test. so pre_export is not called in the same process as post_package_info. I'll change it.
it's pretty annoying that conan-center hook reports not only errors/warnings for the package being built/tested, but for all of its dependencies. they are obviously useless and uninteresting for the contributor.
it's mainly for the
post_package_info
hook right now, as other methods besidespackage_info
(export
,source
,build
,package
) are only executed for the package being built/tested.from the signature of the hook, there is no easy way to say if current conanfile/reference is the main one, or dependency:
there is nothing interesting in public
ConanFile
fields as well.to complicate things, it seems like the hooks object is being re-created each time, so it's not trivial to save any state between method invocations, it's always brand new, constructed from scratch.
the reliable process-wide storage is
sys.modules
, which works well, regardless of how many times python file is loaded.