Tracking issue for config-cli

[ehuss]

Implementation: #7649
Original proposal: #6699
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#config-cli

Summary

Adds --config CLI option to pass config options to any command.

Unresolved issues

• Make TOML restricted to KEY=VALUE. Will need updates to the toml crate to make that possible. DONE: Check --config for dotted keys only #10176
• Make --config PATH work has a shorthand for `--config 'include="path"' DONE: Support --config path_to_config.toml cli syntax. #7901

[jyn514]

A use case for this: docs.rs wants to pass RUSTFLAGS without having the spacing interpreted by the shell: rust-lang/docs.rs#1057

[Nemo157]

Is it not possible to specify registry sources via this? I wanted to migrate from using registry-index sources in Publishing crates to IPFS so that I could test it with #8890, but trying to use this flag to define the registries it doesn't seem to be picked up:

> cargo -Zunstable-options '--config=source.bs58_cli_0_1_0_anyhow.registry="http://127.0.0.1:8080/ifps/QmP6KmpjQrYpYyeXGqAvmrw45dPoKvmKeTqTanmSqJGJKz"' '--config=source.bs58_cli_0_1_0_bs58.registry="http://127.0.0.1:8080/ifps/Qmb2PJ9vMALRFmQjLDQbcNHYUvcFc96XzKMwAhBMEECxzb"' '--config=source.bs58_cli_0_1_0_paw.registry="http://127.0.0.1:8080/ifps/QmNkJbrmpjJErbX9fTpSSQYb7Ky1Qnpg47QptfMcVQUwBx"' '--config=source.bs58_cli_0_1_0_structopt.registry="http://127.0.0.1:8080/ifps/Qmbh5sZbKezvYq2ESVhbnymqs7VKMTaz7yXUaoMi9tBjJp"' update --manifest-path /tmp/ipfs-registry.bs58-cli-0.1.0.yIgXKp/bs58-cli-0.1.0/Cargo.toml
error: failed to parse manifest at `/tmp/ipfs-registry.bs58-cli-0.1.0.yIgXKp/bs58-cli-0.1.0/Cargo.toml`

Caused by:
  no index found for registry: `bs58_cli_0_1_0_anyhow`

[Nemo157]

🤦 ignore that, I was using the wrong config key.

[dancrossnyc]

Curious if there's any updated status on this? It would be really great to get stabilized!

[ehuss]

There's no update. There's still an unresolved issue noted above that needs someone to work on it.

[jonhoo]

I'll add what I think is a pretty compelling use-case for this: passing -Zinstrument-coverage for coverage testing (which is stabilizing in rust-lang/rust#90132). It requires leaving any existing rustflags intact since things like linker flags (-Clink-args) may be required for the crate to build in the first place, which using RUSTFLAGS doesn't do (#5376) but --config='build.rustflags = ["-Zinstrument-coverage"]' does (#5376 (comment)).

For the unresolved issue, some guidance on exactly what you're imagining would be helpful @ehuss. Specifically, why do you think that restriction is necessary in the first place? Alternatively, could we just parse into a toml::Value and then check that it only contains one actual entry?

[ehuss]

The restriction is to just constrain the format so that it has a straightforward syntax. That way, someone wouldn't be able to pass in comments or [bracketed.tables] or newlines or anything like that. It already parses to a toml::Value and checks for one value.

[jonhoo]

👍
Implemented in #10176

[jonhoo]

Now that #10176 has been merged, I think the unchecked box can be ticked!

[michalmuskala]

What are the plans for stabilising those features? My use case is using vendored dependencies on CI (while using "live" dependencies locally). Configuring this through an extra argument to cargo commands with --frozen --config vendor_config.toml rather than overriding the .cargo/config.toml file and using --frozen is very, very convenient and significantly less error prone.

This becomes even more powerful, when I realised cargo vendor outputs the necessary config on stdout (while logging progress on stderr), so using cargo vendor > vendor_config.toml to update the file "just works"

[ehuss]

I think @jonhoo was looking at stabilizing this. @jonhoo, have you had a chance to look at it?

[jonhoo]

@ehuss In my opinion config-cli can be stabilized as-is. I think that's also where we arrived at on Zulip. I think there are improvements we could land that are related to this one (like config-include/#7723), but I don't think those are blockers for config-cli.

[jonhoo]

@ehuss Gentle nudge on this.

[ehuss]

Ah, sorry for the confusion. I was expecting you or someone to post a stabilization PR. Perhaps you were expecting an FCP first. I'll go ahead and kick that off.

@rfcbot fcp merge

@rust-lang/cargo This is a proposal to stabilize the --config CLI option. This option allows one to pass a configuration setting using TOML syntax. The documentation is here.

I'll also propose that this also include the ability to pass --config PATH to specify the path of a config file to load. That is technically part of the config-include unstable option, which I'm not proposing to stabilize right now. I think supporting --config PATH is potentially useful, and I don't have any design concerns about it. config-include on the other hand has questionable utility, and may perhaps need more consideration.

@jonhoo or whoever wants to stabilize this, the general steps for stabilizing something is outlined in https://doc.crates.io/contrib/process/unstable.html#stabilization. To support --config PATH, it will require a small change in the code. I think this cane be done by changing these two lines to instead call self.load_file(…).

[rfcbot]

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

Concerns:

• restricted-values resolved by Tracking issue for config-cli #7722 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[jonhoo]

@ehuss Do you want me to send a stabilization PR for this?

[ehuss]

Yes, please!

[jonhoo]

Vroom vroom: #10755