Skip to content

Re-export uuid crate to use bevy_reflect's uuid version #18723

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

arpadav
Copy link

@arpadav arpadav commented Apr 4, 2025

Objective

As a result, rust-analyzer for a project which requires uuid = "~1.16":

cargo check failed to start: Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(25856))): error: failed to select a version for uuid. ... required by package bevy_reflect_derive v0.15.3 ... which satisfies dependency bevy_reflect_derive = "^0.15.3" of package bevy_reflect v0.15.3 ... which satisfies dependency bevy_reflect = "^0.15.3" of package bevy_ecs v0.15.3 ... which satisfies dependency bevy_ecs = "~0.15" (locked to 0.15.3) of package project v0.1.0 (/home/user/repos/project) versions that meet the requirements =1.12 are: 1.12.1, 1.12.0

all possible versions conflict with previously selected packages.

previously selected package uuid v1.16.0 ... which satisfies dependency uuid = "~1.16" (locked to 1.16.0) of package project v0.1.0 (/home/user/repos/project)

failed to select a version for uuid which could resolve this conflict

Solution

  • Moved the uuid definitions out of bevy_reflect/derive/Cargo.toml (since they do nothing here) to bevy_reflect/Cargo.toml
  • Added pub use uuid to bevy_reflect::__macro_exports
  • Modified the impl_reflect_opaque!(::uuid::Uuid( call to impl_reflect_opaque!(::bevy_reflect::__macro_exports::uuid::Uuid(

Testing

  • Build bevy_reflect without errors
  • Builds my project, using uuid = "~1.16" without the rust-analyzer message see above:
  • I am not a bevy expert, I just wanted to fix this dependency issue, so I would prefer more testing, but I did run the following:
    • Doc tests in bevy using cargo test --doc --workspace: all passed
    • Doc tests in bevy_reflect using cargo test --doc: all passed
    • Unit tests in bevy_reflect using cargo test: all passed
    • However, after grepping for UUID in the bevy_reflect tests I didnt see any tests for it, so I would rather have someone triple-check
  • Tested in Ubuntu x86

Copy link
Contributor

github-actions bot commented Apr 4, 2025

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

@arpadav
Copy link
Author

arpadav commented Apr 4, 2025

Note to maintainers: please feel free to shuffle things around if the final-resting place of my changes is not preferred. I am not married to any of these changes, I just wanted the dependency fix on my end, that's all :)

@mockersf
Copy link
Member

mockersf commented Apr 4, 2025

uuid 1.16 is semver compatible with uuid 1.13, cargo does version unification between the twos and uses uuid 1.16

having as dependencies:

[dependencies]
bevy = "0.16.0-rc.3"
uuid = "~1.16.0"

compiles fine for me, and uses uuid 1.16.

Could you share more about your other dependencies?

@mockersf mockersf added C-Dependencies A change to the crates that Bevy depends on S-Needs-Investigation This issue requires detective work to figure out what's going wrong labels Apr 4, 2025
@alice-i-cecile alice-i-cecile added the A-Reflection Runtime information about types label Apr 5, 2025
@arpadav
Copy link
Author

arpadav commented Apr 6, 2025

My deps, only using bevy_ecs and bevy_time, which were causing the issues:

uuid = { version = "~1.16", features = ["v4"] }
bevy_ecs = "~0.15"
bevy_time = "~0.15"

I moved some code around and just imported bevy instead of its respective bevy_ecs and bevy_time, and you're right: if I change my version to 0.16.0-rc.3 then the issue is resolved.

However, this still doesnt solve the core part of the problem. In a scenario where I want:

uuid = { version = "0.9", features = ["v4"] }
bevy = "0.16.0-rc.3"

Because my project needs a specific uuid version, then this will, yet again, fail:

cargo check failed to start: Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(25856))): Updating crates.io index error: failed to select a version for the requirement uuid = "^0.9" candidate versions found which didn't match: 1.16.0, 1.15.1, 1.15.0, ... location searched: crates.io index required by package project v0.1.0 (/home/user/repos/project) if you are looking for the prerelease package it needs to be specified explicitly uuid = { version = "1.0.0-alpha.1" }

Failed to read Cargo metadata with dependencies for /home/user/repos/project/Cargo.toml: Failed to run cd "/home/user/repos/project" && RUSTUP_TOOLCHAIN="/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu" "/home/user/.cargo/bin/cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/user/repos/project/Cargo.toml" "--filter-platform" "x86_64-unknown-linux-gnu": cargo metadata exited with an error: Blocking waiting for file lock on package cache Updating crates.io index error: failed to select a version for the requirement uuid = "^0.9" candidate versions found which didn't match: 1.16.0, 1.15.1, 1.15.0, ... location searched: crates.io index required by package project v0.1.0 (/home/user/repos/project) if you are looking for the prerelease package it needs to be specified explicitly uuid = { version = "1.0.0-alpha.1" }

And this is solely because when using the derive macro's supplied by bevy, then it still will expand using

impl_reflect_opaque!(::uuid::Uuid(

and it uses the parent crates uuid rather than the bevy crates via

impl_reflect_opaque!(::bevy_reflect::__macro_exports::uuid::Uuid( here

So yes: the temporary fix is for me to use 0.16.0-rc.3, but this issue will come up down the line if uuid is not properly included in some sort of __macro_export module.

And I'm not even using uuid with bevy at all, which is why I made this PR because arbitrary crate restrictions across crates can be solved with a simple fix / proper macro usage, and being beholden to these constraints is unnecessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Reflection Runtime information about types C-Dependencies A change to the crates that Bevy depends on S-Needs-Investigation This issue requires detective work to figure out what's going wrong
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants