Tracking Issue for `-Z patch-in-config`

[jonhoo]

Summary

Original issue: #5539
Implementation: #9204
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#patch-in-config

The -Z patch-in-config flag enables the use of [patch] sections in cargo configuration files (.cargo/config.toml).

Unresolved issues

None known.

Future extensions

None known.

[jonhoo]

Documentation for feature in #9270

[jonhoo]

I'm trying to figure out the best way for me to test this feature, since I don't want to change cargo/rustc we use internally to be nightly, as it might cause developers to start adopting experimental features. I wonder, is there a way to use a cargo -Z feature on beta/stable specifically for this kind of testing? I'd like to be able to opt into just one feature rather than all of them, but "all" cargo features would probably also be fine. I'm thinking something like -Zallow-Zs :p

Alternatively, is there an "inverse" of RUST_BOOTSTRAP to disallow the use of nightly-only features on nightly? 😅

[alexcrichton]

I believe there's an [unstable] table in .cargo/config.toml which can globally enable nightly features, and then if you use nightly Cargo you should be able to use the feature without any opt-in anywhere else

[jyn514]

Alternatively, is there an "inverse" of RUST_BOOTSTRAP to disallow the use of nightly-only features on nightly? sweat_smile

I've suggested adding RUSTC_BOOTSTRAP=0 in the pass (a little whimsically, but I think the idea is good). https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/212978290

[joshtriplett]

I would love to have a mechanism to prevent the use of nightly features, regardless of compiler branch. That'd be helpful, for instance, if using nightly for toolchain reasons (needing specific options or optimizations or targets), but not wanting to make code depend on nightly.

[jonhoo]

Ah, so, I specifically want to disallow all unstable features except one, since I want the ability to test a particular feature without opening the floodgates to all the others.

[jonhoo]

I started an internals discussion over in https://internals.rust-lang.org/t/mechanism-for-beta-testing-unstable-features/14280 for those interested in that line of discussion :)

[jonhoo]

I can report that I've been using this to great success in a fairly large internal developer ecosystem for a while now. What kind of evidence report would be helpful to the Cargo team to aid in making an eventual stabilization decision?

[joshtriplett]

We discussed this in today's @rust-lang/cargo meeting. We felt like, for this feature, the signal that you've used this extensively in a large internal developer ecosystem is enough of a proof point.

We did have one concern that we felt needs addressing before this stabilizes: it sounds like a [patch] in Cargo.toml takes precedence over one in .cargo/config.toml, whereas in most cases, .cargo/config.toml takes precedence over Cargo.toml. We'd like to be consistent there. Could you make .cargo/config.toml consistently take precedence?

Other than that, we think this can be stabilized, and we'd welcome a stabilization PR.

Separately, and not as a blocker from this: it would be nice if cargo publish ignored a variety of configuration bits that would make others unable to reproduce your build, including patch, rustflags, rustc, and similar. If you have the bandwidth, we'd really appreciate a PR implementing that. Please? 😄

[jonhoo]

Exciting! Done in #9839.

That would be a really good change, though given that I don't actually use cargo publish for said internal ecosystem, it's not clear that I'm the right person to do it 😅 In fact, in my situation (for just cargo package, which I do use), I would explicitly want to continue using the patches and other config, because the overarching build system ensures that the same configuration options are set for any consumer that wants to build.

[ehuss]

Sorry, I don't think I expressed my concern about publishing clearly. There are a few concerns here:

• If you have a config file with [patch] inside a binary package, and you publish it, I believe it will continue to use those patches. That would be a sort of runaround of the stability guarantees of crates.io whereby you can depend on crates from anywhere. I haven't tested that, but I believe that is what would happen. I think that is probably something we would want to prevent.

• A lesser concern is that if you have [patch] in ~/.cargo/config, and you run cargo publish (or cargo package), the verification step will use those patches. However, the published package will not have those patches, so it may fail when other users try to use it. I'm less concerned about this, since it unlikely to happen in practice, and if it does, the author can just publish a fixed version.