bevyengine / bevyengine/bevy

Asset file name extension handling should be consistently case-insensitive

Open
#19,476 0 comments 2 reactions 0 assignees View on GitHub
A-Assets C-Usability D-Straightforward S-Needs-Design
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
4d 8m
Merged PRs (30d)
147

Description

I want to argue that the previous behavior was actually better (even though it seems inconsistent at first) :see_no_evil:.

My argument rests on three points
1. that it's more convenient from a user's perspective, for the extension to be case-insensitive
2. that it's more convenient from a plugin author's perspective
3. that there is no good use-case for needing case-sensitive extensions

From a user's perspective: if my assets are coming from a third party, I may not have control over the case of the file extension.
Example: some STL files in [this repository](https://github.com/google-deepmind/mujoco_menagerie/tree/cfd91c5605e90f0b77860ae2278ff107366acc87/unitree_g1/assets) use an uppercase extension, others use lowercase (example shared by @dlhxzb in https://github.com/nilclass/bevy_stl/pull/17).

Similarly when collaborating with people who work on systems with case-insensitive filesystems, asking them to use a consistent case for the extension can create unnecessary friction.

From a plugin author's perspective: suppose I want my users to be able to load files with any case (e.g. `*.stl` files and `*.STL` files as in the example above), then I would need to specify `["stl", "STL"]` as the list of supported extensions.
Once I do that though, one could argue that `*.Stl` should be supported as well. So do I add that to the list too?
Ultimately that decision will be up to the plugin author, so case-sensitivity of file extensions would not be consistent across the bevy ecosystem, as some authors may support only uppercase extensions, while others support only lowercase extensions, while others would support some combination.

This leaves the question: is there a good use-case for case-sensitive extensions?
I can find some examples where it is, but I'd argue they are esoteric.
Looking at the [spec for shared-mime-info's "glob" attribute](https://specifications.freedesktop.org/shared-mime-info-spec/0.21/ar01s02.html#id-1.3.7), it matches extensions case-insensitive by default, unless explicitly requested:
> Applications MUST match globs case-insensitively, except when the case-sensitive attribute is set to true. This is so that e.g. main.C will be seen as a C++ file, but IMAGE.GIF will still use the *.gif pattern.

Looking at the actual usage of the `case-sensitive` attribute in the freedesktop.org database, there are just a few entries:
```
$ grep case-sensitive /usr/share/mime/packages/freedesktop.org.xml






```
None of these look relevant for the bevy asset loader.

Finally, what about @NiklasEi's original issue, of registering an asset loader for the `Custom` extension?
I think this could be solved, by:
1. Documenting that `AssetLoader.extensions` should return all-lowercase strings
2. (optionally) Logging a warning if an `AssetLoader` specifies an extension that contains uppercase characters, pointing to the documentation

_Originally posted by @nilclass in https://github.com/bevyengine/bevy/pull/17065#issuecomment-2933855963_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.