Summary

Original issue: #2362
Implementation: #9302
Design doc: https://hackmd.io/@ehuss/rkjp32Fg_
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#cargo-config
Issues: Z-cargo-config Nightly: cargo config subcommand

cargo config is a new subcommand for displaying config values.

Unresolved issues

• The way environment variables are handled is awkward. When querying a specific value, it can read the environment variable. But when displaying maps, it cannot. This is due to the lazy nature of how environment variables are loaded. This may be impossible to solve (due to the case and dash/underscore translations). Is the way it is displayed reasonable? TOML displays all CARGO_* environment variables as comments, and JSON just prints a note after the first line on stderr (which hopefully shouldn't interfere with parsing).
• A primary use case for this feature is to collect information in issue reports to help diagnose an issue. However, by default cargo config get also includes sensitive information like token. Should there be some way to redact or remove sensitive things?
• Determine how to display manpages for nested subcommands.

Future extensions

• set and delete subcommands. Needs a comment-preserving toml editor.
• edit subcommand which launches an editor. There are some decisions to be made on how it decides which file to edit.
• Display warnings for unknown keys. This would require having a global registry/schema of the config structure.
• Quoted keys aren't handled as CLI input. For example, config get 'target."cfg(target_os=\"linux\")".runner' Unfortunately toml doesn't expose the parsing functions to make this easy. Could do from_str("{} = 1", key), and then collect all the key components. I wouldn't want that in the normal Config.get() path, though, for performance. I think it is fine to stabilize without this, since it can be added later, and is probably not a use case that I can imagine anyone needing.
• Other formats mentioned in the design doc: toml-value, toml-table, sh-value. The only one that seems useful to me is sh-value, but I'm uncertain how that could handle maps (maybe just error in that case?).
• --show-origin and --merged=no only supports TOML. I don't know how JSON could display either of those, and I don't think it is important.
• The design doc mentioned a --includes=no flag to disable include handling. I'm not sure if that is really necessary. The --merged=no flag will show includes and where values are coming from.
• Support displaying the "default" of values. This would require a global registry/schema. This also may be difficult, since TOML doesn't have a way to display none/null/unset, and some defaults are complicated.
• cargo config does not fetch values from Cargo.toml. This could be confusing for things like profiles. There could be a flag like --merge-manifest or --manifest=Cargo.toml to support that?
• Some config values are complex like rustflags, which is merged across multiple config values and environment variables. naively fetching build.rustflags won't necessarily get the flags cargo actually uses. Maybe config get could have special "computed" keys that take this into consideration? (see design doc)

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.