-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Cargo should use standard logging framework #6751
Comments
The logging framework and profiling info is already available I see in |
I just checked and warnings and errors are reported with
I've used logging frameworks in the past for the primary output of my programs and the quality isn't as good. When I tend to shift my focus to the quality of my output, I end up dropping it. Focusing on specific asks, rather than the implementation:
I feel like filtering would be a large ask with limited value, partly from it being hard to get the filters right. I think it would be better to focus on the use cases for filtering to see if there are alternatives. If its just because the output is viewed as noisy generally, then I think that is what we should focus on, rather than on people trying to slice and dice the output. As for timestamping, the motivation given is to "determine where most time is spent in the pipeline" but that won't really help unless we say when things start, and not just when they end. As an alternative, we now have |
Cargo can be invoked with a command line interface, as well as non-interactively.
In the latter case, Cargo may e.g. be used as part of a Continuous Integration pipeline.
For that use case, it is important to reduce noise in the build output. Moreover, it is important to see regular timestamps in order to determine where most time is spent in the pipeline.
Cargo writes a line for every dependency package that is builds, which means a lot of information is output that can be considered noise, in this use case. Currently, Cargo can only be made completely silent using the
--quiet
argument. However, this does not even report errors. This makes this option unattractive to this use case. Cargo also doesn't include timestamps in its output.Similar to most other long-running command line utilities, Cargo should only use a standard logging framework, configurable by the caller. This would make it easy to:
This change should not be complex in terms of design. In case a concern about aesthetics overrides the previous concerns, and suppose it could not be addressed within the proposed solution, then the solution can be limited to a non-interactive context.
The text was updated successfully, but these errors were encountered: