Open BD103 opened 2 months ago
notably this is often required when doing work with early release-candidates, or crates that haven't published their transitive dependencies to crates.io, etc.
One question is if you run bevy patch A
followed by bevy patch B
, will A
be removed from Cargo.toml
and replaced with B
? If so, the command needs to be able to detect existing bevy
subcrate patches. What if the user has e.g. a single manually-written patch like bevy_ecs = { ... }
, will bevy patch
overwrite that? If not, it would have to be able to distinguish between bevy patch
patches and user-written patches, which seems impossible.
Maybe it can comment out previous patches instead of overwriting? But anyways, everyone uses version control so overwriting is probably fine.
I don't necessarily think it needs to modify Cargo.toml, especially in its first form. It just needs to dump the generated list to console. The full list is awkward to access and write out otherwise. Even dumping bevy = { git="<git>", branch = "<branch>" }
for the crate list would be useful (which could then be multi-cursor modified by a user pasting it into their Cargo.toml).
Good point. Even in the final form, it could dump the text by default and include a -w, --write
flag to actually write the patch.
also slight preference for something like bevy patch --list
existing anyway, even if modification is implemented
You can pretty easily find a list of all 1st-party Bevy crates in a workspace by running:
cargo metadata --format-version 1 | jq '.packages[] | select(.name == "bevy_internal") | .dependencies[] | .name'
nice. cooked up a nushell version based on that (mostly for myself soon when 0.15 drops)
cargo metadata --format-version 1 | from json | get packages | where name == bevy_internal | first | get dependencies.name | each {|it| $'($it) = { git = "<git>", rev = "<rev>" }' } | str join "\n"
bevy_a11y = { git = "<git>", rev = "<rev>" }
bevy_animation = { git = "<git>", rev = "<rev>" }
bevy_app = { git = "<git>", rev = "<rev>" }
...
Note that the above two commands do not include bevy_dylib
since bevy
, but not bevy_internal
, depends on it directly.
Thanks to @christopherbiscardi for the original suggestion on Discord.
If you depend on a fork of Bevy and want to patch 3rd-party plugins to use said fork, you need to use dependency overrides. Due to how they work, you have to do one override for each of Bevy's subcrates, which amounts to a lot of patching.
Chris suggested that the Bevy CLI should be able to automatically generate these overrides with a given Git repository.