paths override in .cargo/config but cargo can't find crate

[Boscop]

I'm trying to build ffmpeg on windows (using the latest cargo and nightly rustc-msvc through rustup). This crate depends on rust-ffmpeg-sys which didn't build on windows out of the box so I tweaked it until it did build, as a local fork, at D:\3rdparty\rust-ffmpeg-sys. Next, I wanted to build rust-ffmpeg using my local fork of rust-ffmpeg-sys, so I put this in C:\Users\me\.cargo\config:

paths = ['D:\3rdparty\rust-ffmpeg-sys']

Now trying to build rust-ffmpeg again with this override, I get this error:

d:\projects\forks\rust-ffmpeg>cargo build
   Compiling ffmpeg v0.2.0-alpha.2 (file:///D:/projects/forks/rust-ffmpeg)
error[E0463]: can't find crate for `sys`
 --> src\lib.rs:4:1
  |
4 | pub extern crate ffmpeg_sys as sys;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

error: Could not compile `ffmpeg`.

To learn more, run the command again with --verbose.

verbose output

My intention with the override is that all crates that I try to build with cargo that depend on ffmpeg-sys will use the local version (because otherwise they will fail to build).

Why doesn't the override work?

[alexcrichton]

What does the Cargo.toml for the rust-ffmpeg and ffmpeg-sys crates look like as well? Certainly seems like a bug!

[Boscop]

These are the Cargo.toml files:
rust-ffmpeg
rust-ffmpeg-sys

[alexcrichton]

It looks like may be a version mismatch? The ffmpeg crate is requesting 2.8 where the sys crate you've got is 3.0.

If you update those to match does it work? If so, then we definitely need to improve the error!

[Boscop]

I just tried changing it to

[dependencies.ffmpeg-sys]
version = "3.0.0"

But now I get:

d:\projects\forks\rust-ffmpeg>cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: no matching package named `ffmpeg-sys` found (required by `ffmpeg`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: ^3.0.0
versions found: 2.8.9, 2.8.8, 2.8.7

[alexcrichton]

Oh try changing the version in ffmpeg-sys itself to match 2.8 perhaps?

[nox]

Could we fix this, or relax the version requirement? This is really bothering us Servo people who include bumps in PRs, and we shouldn't be forced to change our workflow IMO.

[Boscop]

@alexcrichton I changed the version in ffmpeg-sys it to 2.8.8 and now it works.
Btw, now I have to always use VS Developer Console when building any crate that depends on ffmpeg-sys, is there a way to build it once so that other crates can just use the prebuilt version?

I also had to modify rust-ffmpeg after that to get it to compile, so I added an override in paths for it too, but now when I compile something that depends on rust-ffmpeg (like rust-openal's play example), I get this:

warning: path override for crate `ffmpeg` has altered the original list of
dependencies; the dependency on `image` was either added or
modified to not match the previously resolved version

This is currently allowed but is known to produce buggy behavior with spurious
recompiles and changes to the crate graph. Path overrides unfortunately were
never intended to support this feature, so for now this message is just a
warning. In the future, however, this message will become a hard error.

To change the dependency graph via an override it's recommended to use the
`[replace]` feature of Cargo instead of the path override feature. This is
documented online at the url below for more information.

http://doc.crates.io/specifying-dependencies.html#overriding-dependencies

[alexcrichton]

@nox the issue I believe you're referring to is unrelated to this.

@Boscop

I changed the version in ffmpeg-sys it to 2.8.8 and now it works.

Yay!

is there a way to build it once so that other crates can just use the prebuilt version?

Unfortunately not currently :(

I get this

Aha indeed! Intrusive changes to the original dependency are actually broken with path overrides. This case where you changed the version is unfortunately yet another case where it's broken and we'll need to give a better error message. If [replace] doesn't work though just let me know!

[Boscop]

Is there a way to do the override globally (for all projects that I build with cargo which require ffmpeg) so that it doesn't give this error / break the dependency?

[alexcrichton]

@Boscop for this sort of application where the version is changing, or dependencies are changing, unfortunately no ([replace] will need to be used instead)

[nox]

@alexcrichton

The documentation says:

Note that when a crate is overridden the copy it's overridden with must have both the same name and version, but it can come from a different source (e.g. git or a local path).

So what can one use to replace a crate with a different version now that neither [replace] nor path overrides allow it?

[alexcrichton]

@nox again this report is not related to [replace], so it'd be best to discuss those issues elsewhere.

[AndiDog]

Created a new issue for the [replace] issues I found: #3263

[goertzenator]

I'm coming here from #3548. [replace] does not work for me for the same reason @nox points out above, so my only alternative is to temporarily change to a path dep for development, ie:

[dependencies]
#erlang_nif-sys = "0.5"
erlang_nif-sys = { path = "/home/goertzen/erlang_nif-sys" }

Other notes/comments

• Path overrides worked for me up until rust-1.12.
• I use https://github.com/sunng87/cargo-release which bumps the crate rev in github after publishing to crates.io, so the git version is always one ahead of what crates.io has.
• Relaxation of version numbers for path overrides seems like a good idea, and I would even consider dropping the requirement of the crate having to be in crates.io. On the flip side, I'd also want to see the publish command fail if any path overrides were in effect (but maybe it does that already?).

[nox]

Any news on this?

[alexcrichton]

No, but there is a possible future solution

[epage]

Looking over this, it seems the original concerns were resolved (version mismatch) and then it led to a separate issue around changing dependencies when replace isn't enough.

As the original issue sounds resolved, I'm going to close. If people are still needing dependency changes for path overrides and can't use replace, I'd recommend creating an issue specifically about that. If there is something I missed that this should be kept open for the original problem, let us know!