Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bevy patch - automatically generate Bevy dependency overrides #79

Open
BD103 opened this issue Sep 16, 2024 · 8 comments
Open

bevy patch - automatically generate Bevy dependency overrides #79

BD103 opened this issue Sep 16, 2024 · 8 comments
Labels
A-CLI Related to the main CLI C-Enhancement A general improvement

Comments

@BD103
Copy link
Member

BD103 commented Sep 16, 2024

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.

image

Chris suggested that the Bevy CLI should be able to automatically generate these overrides with a given Git repository.

@BD103 BD103 added A-CLI Related to the main CLI C-Enhancement A general improvement labels Sep 16, 2024
@ChristopherBiscardi
Copy link

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.

@benfrankel
Copy link

benfrankel commented Sep 16, 2024

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.

@ChristopherBiscardi
Copy link

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).

@benfrankel
Copy link

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.

@ChristopherBiscardi
Copy link

also slight preference for something like bevy patch --list existing anyway, even if modification is implemented

@BD103
Copy link
Member Author

BD103 commented Sep 16, 2024

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'

@ChristopherBiscardi
Copy link

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>" }
...

@BD103
Copy link
Member Author

BD103 commented Sep 16, 2024

Note that the above two commands do not include bevy_dylib since bevy, but not bevy_internal, depends on it directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CLI Related to the main CLI C-Enhancement A general improvement
Projects
None yet
Development

No branches or pull requests

3 participants