Resolving dependency errors

Scenario: A package built using cargo, has a dependency A which has a fix in v0.17. However multiple dependencies further depend on an older versions of A. eg A@0.16.20 and build fails.

Is there a way to globally set that whenever A is encountered always pull v0.17 ?

I have explored the [patch] option however, A not a direct dependency and is almost 3/4th level further in cargo tree. So patching is becoming difficult.

You will need to patch every dependency that has a requirement on A with version 0.16. Cargo doesn't provide a way to override dependency version requirements.

2 Likes

Could you please point to some example on how to patch nested dependencies if available?

[patch] always applies to packages regardless of where they are located in the dependency graph — there is no different syntax for indirect dependencies.

To restate what @bjorn3 said in different terms: you need to add entries in the [patch] table which replace each package that depends on A@0.16 with one which depends on A@0.17.

Alternatively, it might be simpler to patch A@0.16 with a version of A which has the fix but is numbered 0.16.something rather than 0.17. However, then you'll have two versions of A compiled, which might be a problem (if types or traits from A are used/reexported by other dependencies) or might be fine.

2 Likes

Oh, and an even fancier approach is to replace A@0.16 with a small library that re-exports A@0.17's items, to avoid the duplication.

Of course, that will only work if the breaking changes between A@0.16 and A@0.17 don't break the code in any of the dependents of A@0.16.

Got it, so [patch] needs to be applied at the root Cargo.toml and not subsequent ones in dependencies.

Thank you @bjorn3 @kpreid

That too, yes; [patch], like [profile], affects the build as a whole, and such things are never aggregated from individual involved packages, because if they were, they could conflict with each other. Cargo's design tries to minimize ways in which packages can conflict.

1 Like