Asset IO read_directory No Longer Panics on Absolute Path

[bushrat011899]

Objective

• Fixes load_folder() panics when given an absolute path but load() does not #9458

Solution

• Used pathdiff::diff_paths to explicitly create the desired path, which handles the edge case where a provided path is actually an absolute path already, and thus cannot be stripped of a prefix of the general root path for the Asset IO.
• Based on my previous comment

---

Changelog

• Added pathdiff crate to bevy_asset to allow for the creation of relative paths in a platform agnostic manner.
• Fixed read_directory incorrectly assuming a.join(b).strip_prefix(a) == Ok(b)

[github-actions]

Example alien_cake_addict failed to run, please try running it locally and check the result.

[rlidwka]

Can this be done without adding another dependency crate?

[mockersf]

Will probably hold on this until #8624 is merged

[bushrat011899]

Can this be done without adding another dependency crate?

Absolutely! But you'd end up just copying the contents of pathdiff into Bevy, which is antithetical to good open source software composition. Constructing a relative path between two arbitrary Paths isn't particularly trivial, and I would be doubtful that a custom solution for Bevy would actually give much value.

[rlidwka]

Constructing a relative path between two arbitrary Paths isn't particularly trivial

If it takes 43 lines of code, I'd call that very much trivial.

which is antithetical to good open source software composition

So instead of small file with custom implementation somewhere inside the bevy repo, you'll have:

1. one more dependency declared (there are a LOT more people reading Cargo.toml than source files)
2. one more crate to download and compile (each package represents many files on disk - manifest, readme, license - which take more space and processing time than a single file in existing repo)
3. one more license to check and include in all applications (for those companies that like to include all licenses for everything they use)
4. add some risk that a dependency package will be released with incompatible api, and everything breaks
5. (*) including all the issues arising when an end user includes different versions of the same package, where things just straight up don't compile
6. (*) including a risk of new api feature that wipes your hard drive, as with famous node-ipc npm package

I'm not buying into "good open source software composition" idea. But I don't know bevy policies about introducing new dependencies, that's up to maintainers here.

Also, here's a funny read on the subject I just found, contents of which you can probably guess by the title:
https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

[bushrat011899]

If it takes 43 lines of code, I'd call that very much trivial.

Short is not the same as simple.

So instead of small file with custom implementation somewhere inside the bevy repo, you'll have:

1. one more dependency declared (there are a LOT more people reading Cargo.toml than source files)

Bevy currently builds with just shy of 1,000 crates as dependencies depending on your project, a single addition (which itself has 0 dependencies) will make zero difference to anyone who truly believes more dependencies equals bad.

2. one more crate to download and compile (each package represents many files on disk - manifest, readme, license - which take more space and processing time than a single file in existing repo)

Again, Bevy is already including hundreds of dependencies each with anywhere from one to thousands of files, one dependency is not going to meaningfully change that.

3. one more license to check and include in all applications (for those companies that like to include all licenses for everything they use)

See response to points one and two.

4. add some risk that a dependency package will be released with incompatible api, and everything breaks

That's just not how open source dependency management works. You can't say "I'll just make my own solution and put in all the work to maintain it" and "Putting in the work to maintain someone else's version is too hard" at the same time. For this crate in particular I think that's a poor critique, since it has well over 15 million downloads and only 3 versions in its entire lifetime.

5. (*) including all the issues arising when an end user includes different versions of the same package, where things just straight up don't compile

That's only an issue if you expose types from a third party library as your own, which is not happening in this case. And even then, you can still manage this.

6. (*) including a risk of new api feature that wipes your hard drive, as with famous node-ipc npm package

See response to points 1.

I'm not buying into "good open source software composition" idea. But I don't know bevy policies about introducing new dependencies, that's up to maintainers here.

The idea is to minimize double work. This pull request "implements 43 lines of code in 1" thanks to the generous work of the maintainers of pathdiff.

Also, here's a funny read on the subject I just found, contents of which you can probably guess by the title:
https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

This is not comparable. The leftpad controversy largely stems from the fact that there is a native solution to that problem already. There is no std implementation of diff_paths.

I appreciate the criticism, and I'm also new to contributing to Bevy, so I am absolutely open to being told this is a bad fit for Bevy. In my opinion, this is the best solution to this problem, which is why I wrote it an submitted it. If you believe you have a better solution, please make a PR and submit it. Either way, Bevy and its community wins.

[rlidwka]

If you believe you have a better solution, please make a PR and submit it.

okay, sure, here we go: #9490

[github-actions]

Example alien_cake_addict failed to run, please try running it locally and check the result.

[alice-i-cecile]

The linked bug is now fixed: should I close this out?