search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.28k stars 2.32k forks source link

Cargo should use standard logging framework #6751

Open sanmai-NL opened 5 years ago

sanmai-NL commented 5 years ago

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.

sanmai-NL commented 5 years ago

The logging framework and profiling info is already available I see in ARCHITECTURE.md. I propose to let it subsume the main user visible console reporting code in https://github.com/rust-lang/cargo/blob/dc83ead224d8622f748f507574e1448a28d8dcc7/src/cargo/core/shell.rs.

epage commented 8 months ago

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.

I just checked and warnings and errors are reported with --quiet at this time. Does that change the need for this request?

The logging framework and profiling info is already available I see in ARCHITECTURE.md. I propose to let it subsume the main user visible console reporting code in

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:

Allow the caller to filter what to log. Include accurate timestamps and other details in log entries.

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 --timings; you could run that and artifact it. When you really just want timestamps for each line, an approach I've taken before is to write wrapper programs that monitor output and do things like add timing information or produce JUnit output.