No way to silence "WARNING:colcon.colcon_ros.prefix_path.ament: .... AMENT_PREFIX_PATH doesn't contain any 'local_setup.*' files"

[RandomSpaceship]

Pretty much what it says in the title. The relevant line of code is here. Since it's logged with the logging module instead of the warnings module, the COLCON_WARNINGS and PYTHONWARNINGS environment variables have no effect. This also means that if there are any other warnings provided by the logging module, they cannot be easily silenced either. In my project, I'm using nix-ros-overlay to provide a build environment, and due to the way it sets it up, there's a barrage of the aforementioned warnings at the start of every colcon build, which can easily hide genuinely useful warnings and errors.

Perhaps a flag (or new environment variable?) should be added to filter/silence these warnings, especially since they're going to stderr. At the moment I'm piping stderr through a filter to remove the warnings, but I'm not super happy with this solution.

[cottsay]

Hmm, I think this warning is valid. The setup scripts are one of the ament features that set an ament prefix apart from a plain CMake prefix.

Would it be possible for your application to use CMAKE_PREFIX_PATH instead of AMENT_PREFIX_PATH since you aren't actually operating on an ament prefix?

[RandomSpaceship]

I'm not sure: I just don't know enough about the internals of ament/colcon and ROS package installs to know what I'd need to change and what effects it'd have. Going off the overlay source code here, if I'm reading it correctly, it adds the output environment (containing the entire built package set) to every package's CMAKE_ and AMENT_PREFIX_PATHs. Since you're saying that the warning is correct, then the warning being present is an issue with the overlay, not with colcon-ros, and that's fine.

That still leaves the original issue though - yes, it is a valid warning because the user is doing dumb things, but I'd still like a proper way to silence it. My suggestion to resolve the issue would be to log it using the warnings module instead of the logging module, but I admit I don't know enough about the project's architecture to know if that's a bad idea or not.