`ScheduleLabel` proc macro produces code that requires additional dependency apart from its originating crate

[ilyvion]

Bevy version

0.11 and/or main branch

What you did

Put

use bevy_ecs::schedule::ScheduleLabel;

#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
pub struct Render;

in my bevy mod/plugin project

What went wrong

error[E0433]: failed to resolve: use of undeclared crate or module `bevy_utils`
 --> src\render_schedule.rs:3:10
  |
3 | #[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
  |          ^^^^^^^^^^^^^ use of undeclared crate or module `bevy_utils`
  |
  = note: this error originates in the derive macro `ScheduleLabel` (in Nightly builds, run with -Z macro-backtrace for more info)

The code generated by the macro contains

fn as_dyn_eq(&self) -> &dyn bevy_utils::label::DynEq {
    self
}

but I don't have bevy_utils in scope or even as a dependency. It's unclear to me why a derive from bevy_ecs should produce code that requires an entirely different crate to work. Typically if macros require types from other crates to work, they re-export them and refer to them by their re-exported path.

Additional information

My Cargo.toml only has

# Same thing happens with Bevy's git@main
bevy_app = { version = "0.11" }
bevy_ecs = { version = "0.11" }

because those are the only bits of Bevy my crate needs. Or so I thought, anyway.

[nicopap]

The code responsible is here:

bevy/crates/bevy_macro_utils/src/lib.rs

Line 173 in d6e95e9

let bevy_utils_path = BevyManifest::default().get_path("bevy_utils");

You do have bevy_utils as a dependency, since bevy_ecs depends on it. So adding bevy_utils as direct dependency won't increase your compile times.

It should however not error-out in those conditions. SystemSet doesn't have the issue, yet it basically works exactly like ScheduleLabel. So I see one of two solutions:

1. re-export DynEq in bevy_ecs
2. Change the ScheduleLabel trait so that it doesn't directly name DynEq, but instead make it work similar to SystemSet