dependencies: registry vs git

[mikedilger]

Servo itself builds. But not my project depending on libservo. For context, I'm trying to build it for the first time in a long time.. this possibly isn't a recently created situation/bug.

webrender_surfman expects surfman 0.2 things and finds surfman 0.1.4 things. This is because it's pulling in registry versions of surfman rather than git versions.

... but that's what components/canvas/Cargo.toml is asking it to do. So I don't get how servo itself magically builds with the newer git versions instead.

The dependencies come out like this for me

playbrowser v0.0.1 (/z/devel/BROWSER/playbrowser)
...
├── libservo v0.0.1 (/z/devel/BROWSER/servo/components/servo)
...
│   ├── canvas v0.0.1 (/z/devel/BROWSER/servo/components/canvas)
...
│   │   ├── surfman v0.2.0

Notice the version of surfman is coming from the registry, not git.

When servo itself builds with mach, however, it somehow pulls in the git version of surfman (which works):

canvas v0.0.1 (/z/devel/BROWSER/servo/components/canvas)
├── surfman v0.2.0 (https://github.com/servo/surfman#2283acaa)
...

How can I get the same behavior in my dependency... or should canvas's Cargo.toml be changed?

I've tried a lot of cargo update 'precise' attempts but I'm just not getting it.

[mikedilger]

I should add that I copy servo/Cargo.lock into my project and let cargo build "fix" it when I compile. That used to work and still mostly does.

[jdm]

The secret is https://github.com/servo/servo/blob/master/Cargo.toml#L18-L34. I also ran into this problem recently trying to build something that relied on Servo, and I had to use a local path override for surfman-chains to modify https://github.com/asajeffrey/surfman-chains/blob/fab4596b7fda814ebbbf48aaa27e250bb693ad06/surfman-chains/Cargo.toml#L20 to point at the same specific git revision to make the build succeed.

[mikedilger]

Thank you @jdm , works like magic

[SimonSapin]

@jdm Shouldn’t we eventually remove those surfman overrides? Either publish appropriate versions to crates.io, or switch everything to using git URLs in [dependencies].

I feel there isn’t a good reason to land uses of [patch] in master when we control all repositories and crates involved.

[jdm]

@asajeffrey is in the best position to answer.

[asajeffrey]

@SimonSapin yes, those overrides should go away once layer management is in place.

For the policy thing of should we ever use [patch] in master, it's complicated. Yes, we could use git URLs everywhere for temporary non-crates.io versions, but that would mean a complex multi-repo update dance when the crate gets puplished and we can go back to using the crates.io version.