[Merged by Bors] - Fix path used by macro not considering that we can use a sub-crate #3178
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NiklasEi
added
C-Bug
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Nov 29, 2021
…3178) # Problem Let's say I am writting a simple bevy plugin, and I want to depend on `bevy_ecs` crate instead of depending on the full `bevy`. So I write the following: *Cargo.toml*: ```toml [dependencies] bevy_ecs = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886" } ``` *lib.rs*: ```rust use bevy_ecs::prelude::*; #[derive(Debug, Default, Component) pub struct MyFancyComponent; ``` So far, so good. Everything works. But let's say I want to write some examples for using my plugin. And for theses I'd like to use the `bevy` crate, so that I can write complete examples (rendering stuff, etc.) that are simple and look like what the consumer of my plugin will do (`use bevy::prelude::*` and `DefaultPlugins`) So I amend my *Cargo.toml*: ```toml [dependencies] bevy_ecs = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886" } [dev-dependencies] bevy = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886", default-features = false } ``` And that leads to a complilation error ``` error[E0433]: failed to resolve: use of undeclared crate or module `bevy` ``` Basically, because `bevy` is in the `dev-dependencies`, the macro (of the production code) decides to use the `bevy::ecs` path instead of `bevy_ecs`. But `bevy` is not available there. ## Solution This PR fixes the problem. I amend the macro utility responsible of finding the path of a module. If we try to find a path, we first test if this correspond to a crate that the user directly depend on. (Like, if we search for `bevy_ecs`, we first check if there is a `bevy_ecs` dependency). If yes, we can depend on that directly. Otherwise, we proceed with the existing logic (testing `bevy` and `bevy_internal`)
|
Build failed: |
|
check fails on reddit links, ignored in #3223 |
|
bors retry |
bors bot
pushed a commit
that referenced
this pull request
Nov 29, 2021
…3178) # Problem Let's say I am writting a simple bevy plugin, and I want to depend on `bevy_ecs` crate instead of depending on the full `bevy`. So I write the following: *Cargo.toml*: ```toml [dependencies] bevy_ecs = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886" } ``` *lib.rs*: ```rust use bevy_ecs::prelude::*; #[derive(Debug, Default, Component) pub struct MyFancyComponent; ``` So far, so good. Everything works. But let's say I want to write some examples for using my plugin. And for theses I'd like to use the `bevy` crate, so that I can write complete examples (rendering stuff, etc.) that are simple and look like what the consumer of my plugin will do (`use bevy::prelude::*` and `DefaultPlugins`) So I amend my *Cargo.toml*: ```toml [dependencies] bevy_ecs = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886" } [dev-dependencies] bevy = { git = "https://github.com/bevyengine/bevy.git", rev = "94db0176fecfac7e7e9763f2dc7458a54c105886", default-features = false } ``` And that leads to a complilation error ``` error[E0433]: failed to resolve: use of undeclared crate or module `bevy` ``` Basically, because `bevy` is in the `dev-dependencies`, the macro (of the production code) decides to use the `bevy::ecs` path instead of `bevy_ecs`. But `bevy` is not available there. ## Solution This PR fixes the problem. I amend the macro utility responsible of finding the path of a module. If we try to find a path, we first test if this correspond to a crate that the user directly depend on. (Like, if we search for `bevy_ecs`, we first check if there is a `bevy_ecs` dependency). If yes, we can depend on that directly. Otherwise, we proceed with the existing logic (testing `bevy` and `bevy_internal`)
bors
bot
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Let's say I am writting a simple bevy plugin, and I want to depend on
bevy_ecscrate instead of depending on the fullbevy.So I write the following:
Cargo.toml:
lib.rs:
So far, so good. Everything works. But let's say I want to write some examples for using my plugin. And for theses I'd like to use the
bevycrate, so that I can write complete examples (rendering stuff, etc.) that are simple and look like what the consumer of my plugin will do (use bevy::prelude::*andDefaultPlugins)So I amend my Cargo.toml:
And that leads to a complilation error
Basically, because
bevyis in thedev-dependencies, the macro (of the production code) decides to use thebevy::ecspath instead ofbevy_ecs. Butbevyis not available there.Solution
This PR fixes the problem. I amend the macro utility responsible of finding the path of a module.
If we try to find a path, we first test if this correspond to a crate that the user directly depend on. (Like, if we search for
bevy_ecs, we first check if there is abevy_ecsdependency). If yes, we can depend on that directly. Otherwise, we proceed with the existing logic (testingbevyandbevy_internal)