Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Add "warnings as errors" mode #14909

Closed
1 task done
rconde01 opened this issue Oct 11, 2023 · 5 comments · Fixed by #15149
Closed
1 task done

[feature] Add "warnings as errors" mode #14909

rconde01 opened this issue Oct 11, 2023 · 5 comments · Fixed by #15149
Assignees
Labels
component: ux No changes to core business logic type: feature
Milestone

Comments

@rconde01
Copy link

What is your suggestion?

For example, sometimes when i'm developing a package I get: "Warning: No files in package"...I would like that to show up as an error. Of course, I guess that also implies the need to suppress warnings - so perhaps it's not so simple.

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Thanks for the suggestion @rconde01

There is already some capability of suppressing warnings in Conan 2.0 with core:skip_warnings
I think this is a valid feature request and something we would be interesting to provide. It is true that core:skip_warnings is not capable of suppressing all warnings, only those that are tagged now (only a few are, with "deprecation"), but that shouldn't be a stopper to provide this, lets discuss it with the team.

@memsharded memsharded added type: feature component: ux No changes to core business logic labels Oct 12, 2023
@rconde01
Copy link
Author

For additional context, 2 other places i've seen warnings are patches and/or replace_in_file not applying correctly. I would say as a rule one should architect such that these apply, or are errors. Seems pretty risky otherwise and could be difficult to debug downstream.

@memsharded
Copy link
Member

For additional context, 2 other places i've seen warnings are patches and/or replace_in_file not applying correctly. I would say as a rule one should architect such that these apply, or are errors. Seems pretty risky otherwise and could be difficult to debug downstream.

I think these would deserve their own separate ticket, as it is a different one.
The replace_in_file by default will raise an error, not a warning, if not successful. It has an opt-out strict=False, but otherwise it will raise an error. Same as patch(). But if they dont, I agree it would be better if they raised an error (not that it could be changed now without breaking)

@rconde01
Copy link
Author

rconde01 commented Oct 13, 2023

hmm...but if the feature is "warnings as errors" then it's a bit weird if they don't cover these cases. But I see that indeed it's an edge case. You don't want to break any recipes, though you could make the policy to not allow strict=False in conan center for updated recipes. I guess the choice to show a warning is weird here. Either

  1. You didn't select strict=False and you want an error on failure.
  2. You specified strict=False implying "hey - i know what i'm doing here and this behavior is expected"...warnings seem like noise then.

Could change these cases to something like: Info: replace_in_file didn't replace anything. if it's really important to see it.

@memsharded
Copy link
Member

Implemented in #15149 for next 2.0.15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ux No changes to core business logic type: feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants