cargo vendor should support OS support restrictions

[wbl]

Describe the problem you are trying to solve
I need to vendor dependencies to ensure that the source repo is the only thing required to build to meet , and only target linux amd64 and linux arm64. However, cargo vendor includes dependencies for targets I don't care about, which ultimately ends up with fat dlls in my git repo.

Describe the solution you'd like
I would like to have a Cargo.toml setting that tells cargo vendor and the rest of the toolchain we only care about certain operating systems or operating system families, and reduces the crates vendored accordingly.

Notes

[Eh2406]

This is an idea that has been rattling around in various forms for a long time. There is an invariant that is really important to making Cargo work so well for collaborative projects. The Lockfile is generated exactly the same no matter what system is generating it. "solutions" that break that invariant are dead on arrival. I think I can sketch out a design that will work, or at least it goes over well in all the informal conversations I have had. It will take a lot of implementation work, and will need an RFC before we can stabilize it. But let me right it up here so if someone wants to run with it, they can.

1. add a flag in Cargo.toml that is like target_allow_list. (bikeshed allow/deny/cfg, or multiple with interactions)
2. then

• a. If building a final artifact on a target that is blocked by the flag, Cargo will error before it even wrights a lockfile.
• b. If building a final artifact on a target that is allowed by the flag, then Cargo will ignore cfged dependencies that cannot be matched by the flag. (note: we probably do not want a SMT solver to decide this question, so we may have to limit the flag. This may argue for an allow instead of cfg in the flag.)
• c. If building an intermediate artifact. Three options. The easy way out, error at build time. "winapi can not be built for your target use cfg to not depend on it on your target." The odd duck, just skip building it. "winapi is not compatible with your target so was not built. ... can not compile foo, use winapi but no crate by that name exists." Or the hard way, integrate it into resolution. Make it so a dependent crate with the flag can only be imported by a parent crate that has a more restrictive flag or by a cfged dependency that is more restrictive. (This last option makes the SMT concerns much worse, as the resolver may have to ask this compatibility question a large number of times. Exponential in theory, probably only quadratic with caching.)

As I write this up, there may be complexities having to do with target/host. But there is a sketch for someone to get started with.

[wbl]

Naive question: does the vendor directory have to vendor everything in the lockfile?

[est31]

Dupe of #7058

[est31]

@wbl Cargo can't really "parse" lockfiles in that it uses them as sole source of information for compiling a crate graph. It always needs a second source of information to compare a lockfile to. In fact, the internal algorithm uses the second source as main method to determine a resolved graph, and uses the lockfile only to fill in the gaps (like concrete versions). In the general use case, comparing the lockfile to the second source makes total sense because cargo needs to be aware if you e.g. changed your Cargo.toml to increase some semver version. Then Cargo needs to be able to react and possibly update the version. And in the general use case, the index is already available so it's no big deal, as that is used as "second source". But for cargo vendor, no index is available, so Cargo needs the full sources as that main source to build the crate graph.

Of course for vendored use cases, this design choice seems wrong, but it wasn't the main use case that cargo was designed for at the start.

[ehuss]

I'm going to close this as a duplicate of #7058.