Is There An Elegant Way to Support Latest Git and Latest Release Dependencies?

help
1

I've got an issue where I want to publish a crate, but I want it to be usable for both the latest release of Bevy, which right now is 0.4 and the latest git version of Bevy ( 0.5, but unreleased ) I tried something like this in my Cargo.toml, but it doesn't like the Git repo dep:

[features]
default = ["bevy-0-4"]
bevy-0-4 = ["bevy_0_4"]
bevy-0-5 = ["bevy_0_5"]

[dependencies]
bevy_0_4 = { package = "bevy", version = "0.4", optional = true }
bevy_0_5 = { package = "bevy", version = "0.5", git = "https://github.com/bevyengine/bevy.git", optional = true }

From what I've seen this is impossible because crates.io doesn't tolerate the Git dependency, but I wanted to post here just to make sure nobody has ever managed this first.

2

Write the dependency normally without the git marker. The users of your crate can then use a [patch.crates-io] section in their Cargo.toml to override your dependency to the git one.

1 Like
3

Ah, that's actually pretty nice. Thanks!

4

[patch] only works when the version in the Cargo.toml of the override is the same as the original version.

2 Likes
5

No offense intended, but…

Is there some chance that this might be an XY Problem?

You say you want your published crate...

to be usable for both [versions of bevy]

(my emphasis) Does that imply that bevy will be calling your published crate? In that case is bevy in the Cargo.toml you show above, really more of a dev-dependency? Or is there some other way that you can break the seemingly circular dependency?

6

@dekellum my crate is a Bevy plugin, so Bevy will be using it, and it will be using Bevy. The user using my crate will have something like this in the Cargo TOML, in the case that they want to use master version of Bevy:

[dependencies]
bevy = "0.4.0"
bevy_ldtk = { path = "../bevy_ldtk", features = ["bevy-unstable"] }

[patch.crates-io]
bevy = { git = "https://github.com/bevyengine/bevy.git "}
7

So I don't know anything about Bevy, but are your sure you can't make your Bevy dependency a dev-dependency or a build-depedency only?

Or maybe Bevy should ideally have a split out second crate, e.g. bevy-plugin-interface that you could have as a dependency?

8

Yes, because I need to use bevy's types and such in the Plugin, for instance I need to implement the BevyPlugin trait.

Maybe it could be split out to an interface, but technically that'd have the same issue, because the interface could still have breaking changes just like the crate itself.

It's fine that they have to do a weird patch thing anyway, I think, because if they are using Bevy from master, they're already going off the beaten road a bit.

1 Like
9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.