Stabilize -Z avoid-dev-deps as --minimal-cargo-lock

[infinity0]

Original issue: #4988
Implementation: #5012
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#avoid-dev-deps
Issues: Z-avoid-dev-deps Nightly: avoid-dev-deps

-Z avoid-dev-deps flag avoids installing dev-dependencies in certain targets like install.

@alexcrichton thinks that "in the long run [this wants] to be something like --minimal-cargo-lock which prunes all non-relevant dependencies like platform-specific dependencies that don't apply, dev-deps if you're not building tests, etc."

[matklad]

@infinity0

Clarification question: am I correct that cargo install currently avoids dev dependencies even if the flag is not specified? That is, this issue is specifically for cargo build command?

[infinity0]

@matklad when I last touched that code, yes. the dev_dependencies_no_check test is for this.

[ignatenkobrain]

@infinity0 do you have some patch for this?

We wanted to not package some optional dependencies and hit this issue.

[ignatenkobrain]

\cc @keszybz

[ignatenkobrain]

and also deps for disabled features, I hope. Right?

[infinity0]

@ignatenkobrain Cargo already carries this functionality as cargo build -Z avoid-dev-deps or cargo install (with no extra flags) but only for dev-dependencies, not optional dependencies or unused features or unused target-specific dependencies. No I don't have a patch for the other things I mentioned.

[ignatenkobrain]

@alexcrichton any chance to get someone to work on this? I'm pretty sure that all distributions which decide to package crates will get hit by this.

[phi-gamma]

What needs to be done in order to get his option stabilized?

Cargo pulling in Windows and Redox deps unconditionally is currently
forcing us to patch the Cargo.toml files of numerous crates. It would
remove a lot of friction if this behavior could instead be disabled globally.

[ehuss]

Sorry, at this time we don't have this particular feature on a path towards stabilization. We recognize that there are circumstances where it solves a problem, but we feel like the design hasn't been completely fleshed out, and nobody on the team has the time right now to shepherd that design.

[dkg]

fwiw, this looks like it needs to be resolved to fix problems with debian's autopkgtest suite and multiple crates.

[est31]

I think this is subsumed by #7916

[cuviper]

I think this is subsumed by #7916

It doesn't seem so. I tried by running cargo vendor >.cargo/config, then removing some of the dev-deps. I could still build with -Z avoid-dev-deps, but not with -Z features=dev_dep.

cargo 1.43.0-nightly (bda50510d 2020-03-02)

[est31]

Hmm right good point. I think the difference between the two features is that -Z features=dev_dep still compiles the dev dependencies, just doesn't unify features any more while -Z avoid-dev-deps does not compile them at all

[alekspickle]

Any chance this can take shape any time soon?
It's would greatly help with consolidating async\non-async stuff in domain-oriented crates IMO.

Right now I still have to build all async stuff just for tokio::test 😞

[SpriteOvO]

For people who are using stable version numbers to cargo check MSRV (so can't use nightly), there is a dirty hacky workaround.

[SteveLauC]

For people who are using stable version numbers to cargo check MSRV (so can't use nightly), there is a dirty hacky workaround.

Thank you for this workaround!