Support [term] configuration in Cargo config.toml for color and logging

[suaviloquence]

Describe your use case

According to the config linked by obi1kenobi here, the base cargo tool supports configuring color and logging in the [term] section of Cargo.toml config.toml. As an extension to cargo, it makes sense to allow these values to configure cargo-semver-checks as well, if set.

Describe the solution you'd like

cargo-semver-checks reads the configuration from the [term] section of config.toml to configure color and logging level if they are set. We would have to set precedence rules between this, env vars like CARGO_TERM_COLOR and CARGO_TERM_QUIET, and config flags like --color and --verbose, and it would make sense to follow the same rules that cargo does.

Alternatives, if applicable

No response

Additional Context

I can work on implementing this if it seems like something we want.

[obi1kenobi]

I think these are settings in config.toml not Cargo.toml.

Right now they are a nice to have, similar to the anstyle migration. If this feature is added, most people won't notice, a few will be happy, and nobody will object. That's great, and if you're excited to work on it — I'm happy to support you in that.

We have many other work items with higher impact: writing new lints, resolving some false-positives, improving the use of cargo-semver-checks in large workspaces (along the lines of #600), and of course all the GSoC project ideas.

If you are optimizing for positive community-wide impact per time spent, I'd be happy to suggest a few concrete things you could take a look at. If you are excited about this feature specifically, I'm all in favor and happy to support you here.

[suaviloquence]

I think these are settings in config.toml not Cargo.toml.

oops, fixed.

If you are optimizing for positive community-wide impact per time spent, I'd be happy to suggest a few concrete things you could take a look at. If you are excited about this feature specifically, I'm all in favor and happy to support you here.

I just saw this and wanted to note it as something we could work on. I can definitely do this, but I can definitely work on more of the higher-priority items that you had in mind. What were you thinking of?

[obi1kenobi]

If you're interested in chasing down and fixing some false positives, #727 is great. False-positives in general are very high-priority items because they erode users' trust in cargo-semver-checks.

Improving user-facing error messages are also generally important, since they help onboard new users more effectively while also decreasing maintainers' support burden: the more users can figure out how to do themselves, the fewer questions they'll need to ask about it. #723 is great low-hanging fruit here, and there are likely more in the issue tracker.

Decreasing maintainer burden and improving efficiency is also always great. #665 is a good example.

The work on #600 itself will be a long arc (probably a month or two), but you could help make a big dent in that timeline by augmenting our test suite to include test cases for each of the edge cases mentioned in #600. Roughly, half the work there is design & implementation, and the other half is making sure we have in fact actually solved the problem and won't accidentally break it again in the future. PRs reproducing each problem in test cases would be very helpful for that!

All of these have natural stopping points along the way, which is nice in case you have classwork or other responsibilities that come up. You'll be able to make impactful contributions steadily and without a large up-front time commitment.