Normalise root path in file_watcher

[theon]

Objective

• I hit an issue using the file_watcher feature to hot reload assets for my game. The change in this PR allows me to now hot reload assets.
• The issue stemmed from my project being a multi crate workspace project structured like so:

└── my_game
    ├── my_game_core
    │   ├── src
    │   └── assets
    ├── my_game_editor
    │   └── src/main.rs
    └── my_game
        └── src/main.rs

• my_game_core is a crate that holds all my game logic and assets
• my_game is the crate that creates the binary for my game (depends on the game logic and assets in my_game_core)
• my_game_editor is an editor tool for my game (it also depends on the game logic and assets in my_game_core)

Whilst running my_game and my_game_editor from cargo during development I would use AssetPlugin like so:

default_plugins.set(AssetPlugin {
  watch_for_changes_override: Some(true),
  file_path: "../my_game_core/assets".to_string(),
  ..Default::default()
})

This works fine; bevy picks up the assets. However on saving an asset I would get the following panic from file_watcher. It wouldn't kill the app, but I wouldn't see the asset hot reload:

thread 'notify-rs debouncer loop' panicked at /Users/ian/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_asset-0.12.1/src/io/file/file_watcher.rs:48:58:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Solution

• The solution is to collapse dot segments in the root asset path FileWatcher is using
• There was already bevy code to do this in AssetPath, so I extracted that code so it could be reused in FileWatcher

[github-actions]

Welcome, new contributor!

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

[alice-i-cecile]

I'm on board: this is a reasonable bug fix, and I really like pulling out this code into a reusable method.

[alice-i-cecile]

It would be nice to add a link here, but I'm happy with this now :)

[nicopap]

Good call!

However, I think this would make more sense implemented as a standalone function, rather than an extension trait. I find the .normalized() in let root = super::get_base_path().join(root).normalized(); to be very confusing, while if it was just a normal function call like normalize_path(super::get_base_path().join(root)), it's easier to understand it's not a method on PathBuf, and something defined by bevy instead.

[theon]

Good call!

However, I think this would make more sense implemented as a standalone function, rather than an extension trait. I find the .normalized() in let root = super::get_base_path().join(root).normalized(); to be very confusing, while if it was just a normal function call like normalize_path(super::get_base_path().join(root)), it's easier to understand it's not a method on PathBuf, and something defined by bevy instead.

That's fair; happy to change that 👍

[theon]

@nicopap I've make the change to a standalone function
@alice-i-cecile I added a link to the RFC in the docstings at the same time