ignore source options in config.toml

[nicolasavru]

Running cargo vendor-filterer fails when config.toml is already configured with crates.io source replacements:

$ cargo vendor-filterer
error: Executing cargo metadata (first run): Error during execution of `cargo metadata`: error: failed to get `anyhow` as a dependency of package `wprs v0.1.0 (/home/rasputin/wayland-dev/rust/wprs)`

Caused by:
  failed to load source for dependency `anyhow`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to update replaced source registry `crates-io`

Caused by:
  failed to read root of directory source: /home/rasputin/wayland-dev/rust/wprs/vendor

Caused by:
  No such file or directory (os error 2)

Working around this (AFAIK) requires an annoying dance of blowing away config.toml, running cargo vendor-filterer, and then restoring config.toml. It would be nice if cargo-vendor-filterer ignored crates.io source replacements.

cargo-vendor does this:
alexcrichton/cargo-vendor#23
alexcrichton/cargo-vendor@03e252f

[msirringhaus]

Just FYI: I quickly looked into this, and it doesn't seem to be that easy to fix. vendor-filterer is calling cargo metadata, which errors out.
cargo metadata doesn't provide any way to ignore this config-option. The --config-flag can only add or change options, but not remove them:
rust-lang/cargo#8112
rust-lang/cargo#8687

From what I can tell, there is nothing vendor-filterer can do here, but wait for upstream to implement either the possibility to remove config-settings or skip the source-entry in metadata.

[cgwalters]

Hm, maybe we could detect this situation and create a copy of Cargo.toml in a temporary place without that config, and then use --manifest-path to point to it? But yes, clearly better to add upstream.

[deitch]

I just stumbled across this issue, was digging into the source, found the cargo metadata call, and then found this issue.

cargo metadata --no-deps does not try to read all of the deps, just what is in the Cargo files. Of course, then it

I also took a brief look at how cargo vendor itself works. The ops::vendor function is public, not sure if there is something we can gather from there?

Either way, I am kind of confused.

• cargo vendor ignores redirected sources for metadata in order to be able to vendor, since if it respected them, it would be in a catch 22
• cargo vendor-filtered respected redirected sources, and so gets stuck in the catch-22, because any config that expects top use vendored sources will redirect to vendor/.

Either way, is --no-deps the right path to use? Read just the direct declared dependencies, and then resolve from there, which is kind of what cargo vendor looks like it does?

And is there any workaround for now?