Closed emersonknapp closed 4 years ago
The choice to make this a warning was made in the very first iteration of this around 2 years ago. I don't recall a specific reason why making it a warning was chosen.
I completely agree with your point that it is similar to passing a not existing package name - the user passed something explicitly which doesn't exist. So converting this case into an error which aborts the execution sounds absolutely viable to me.
Please see #26 for the proposed change.
I'm creating a workflow where I dynamically choose a mixin and invoke colcon, and would like to fail the build if the given mixin name isn't found for the verb.
As is, this is just a warning, and I'm not sure how I could exit execution early in this case
This starts as a question: is there a way I could currently enforce that all selected mixins exist? If not, would it be reasonable to add a feature for enforcing this? My instinct is that the default case should be an error, because the user intentionally asked for something, and by analogy
--packages-up-to
exits with an error if the package is not found (though conversely--packages-select
does not, it just builds 0 packages and emits a warning)