# Defining Dependency Versions Remotely **URL:** \ **Category:** cargo\ **Created:** [April 20, 2025, 6:23am UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773 "2025-04-20T06:23:46Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![psichokenetic](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/psichokenetic/32/13176_2.png) [@psichokenetic](https://internals.rust-lang.org/u/psichokenetic)\ **Post date:** [April 24, 2025, 12:42pm UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/21 "2025-04-24T12:42:14Z")
> [@epage](#): > > Have test upgrades you do on core packages before updating the global set, etc. This, and if it works, I copy the string over to the other Cargo.tomls when I get around to it. The present world with multi-repo is nothing to marvel at. ---
**Author:** ![idanarye](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/idanarye/32/3346_2.png) [@idanarye](https://internals.rust-lang.org/u/idanarye)\ **Post date:** [April 25, 2025, 1:35am UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/22 "2025-04-25T01:35:09Z")
If the goal is to keep versions of common dependencies in sync, then I'd rather let dependencies refer to each other: ```toml [dependencies] foo = "^3.14" bar = "^2.71" baz = { same_as = ["foo", "bar"] } ``` - This will make the crate use the same version of `baz` that `foo` and `bar` use. - If `foo` and `baz` use different-but-compatible version requirements - e.g. `foo` needs `>=0.2.3` while `bar` needs `>=0.2.4` - it'll just have them both use a version they both accept. - If `foo` and `bar` require incompatible versions of `baz` - cargo should fail with an appropriate error message. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [April 25, 2025, 1:39am UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/23 "2025-04-25T01:39:12Z")
That is discussed earlier. For more information on the idea, see [3516-public-private-dependencies - The Rust RFC Book](https://rust-lang.github.io/rfcs/3516-public-private-dependencies.html#caller-declared-relations). That only helps make sure that baz uses the same version requirement/range as `foo` and `bar` but does not ensure that `foo`, `bar`, and `baz` use the same precise versions some external source which is the request in this issue. ---
**Author:** ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)\ **Post date:** [April 25, 2025, 6:32am UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/24 "2025-04-25T06:32:57Z")
Where one has such stringent compatibility requirements, I've just exported the inner dependency crate from the `foo` or `bar` crates to use directly. For example, `ghostflow_gitlab` offers APIs around the `gitlab` crate and, because the version is hard to specify properly as a `ghostflow_gitlab` consumer, instead `ghostflow_gitlab::gitlab` is used. ---
**Author:** ![psichokenetic](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/psichokenetic/32/13176_2.png) [@psichokenetic](https://internals.rust-lang.org/u/psichokenetic)\ **Post date:** [May 3, 2025, 6:15am UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/25 "2025-05-03T06:15:22Z")
> just exported the inner dependency crate As an interim, I've considered re-exporting our dependencies to a "pinning" crate. This might actually help the developer experience since all of our main dependencies would just complete off of same `pinning::foo` pattern. When using a polyrepo pattern for services, each new service requires us to add multiple dependencies to the Cargo.toml. Even if the version resolution was delegated out, the dependency names don't complete off of a common list. Using a type name the first time frequently requires adding the type in three places if not using the fully qualified name. Even after we switch to a private registry for other reasons, having the list of our frequent direct dependencies in a consolidated form would still add value in the form of completion for frequent direct dependencies. Our common crate, which is rather monorepo style, embodies this kind of solution already. If a crate only uses the re-exported common interfaces, we can often alleviate the need to list the dependency or maintain version parity at all. To combat fat binaries, I bet I would have to add some features. Our common crate does this. With a shared target (configured by .cargo/config.toml), all projects can share targets fairly easily, so re-using builds has been achieve a while ago. I haven't thought though the lockfile implications of re-export as a workaround. ---
**Author:** ![pitaj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pitaj/32/11262_2.png) [@pitaj](https://internals.rust-lang.org/u/pitaj)\ **Post date:** [May 3, 2025, 1:42pm UTC](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773/26 "2025-05-03T13:42:50Z")
> [@psichokenetic](#): > > To combat fat binaries, I bet I would have to add some features. If you aren't actually using the code, it is extremely unlikely to be present in the final binary. Otherwise everyone would get a full copy of the stdlib for every binary. [Previous page](https://internals.rust-lang.org/t/defining-dependency-versions-remotely/22773.md?page=1)