Remove the directories dependency

[YgorSouza]

eframe now has its own logic to find the storage_dir to persist the app when the persistence feature is enabled, instead of using the directories crate. The directory should be the same as before (verified with a unit test).

• Closes Replace directories dependency #4884
• I have followed the instructions in the PR template

[bircni]

Good idea - this should be documented somewhere for users who will search for it

[YgorSouza]

Good idea - this should be documented somewhere for users who will search for it

I fixed the comment style in the Cargo.toml. Now it should be automatically added to the Feature Flags section in the docs, thanks to the document-features crate. Thank you.

[emilk]

Should this be a default feature to avoid breaking changes?

How often does the naive approach fail, and directories be required?

[YgorSouza]

The problem with making it default is that people using eframe without persistence would have the directories dependency even though it isn't being used for anything, unless they pass --no-default-features.

This naive function relies on default environment variables, so it will fail on custom environments that don't have those variables. I'm not sure how often that comes up for eframe users.

Another option would be to use the home crate (which eframe already depends on indirectly) to get the paths on Linux and macOS, and a modified version of this code to get the appdata path on Windows. I think that would completely reproduce what directories does, and then it could be removed or left as a dev dependency for the unit test.

[YgorSouza]

I made the change to just replicate what directories does entirely instead of using the naive approach. If it's too much unsafe/windows-specific code to be in eframe, we could use the etcetera crate instead, as suggested in the issue. Although it is a bit outdated with respect to the home crate at the moment.

[emilk]

This doesn't seems enough to sanitize the path 😬

https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names

I suggest we replace all characters not in [a-zA-Z0-9_-]

[YgorSouza]

This is actually just replicating what the directories crate does.

The Linux impl changes the text to lowercase and removes spaces:

https://github.com/dirs-dev/directories-rs/blob/da65f064a8bb18d790600433fadeed17a54c793a/src/lin.rs#L92-L110

The macOS impl changes the spaces to dashes:

https://github.com/dirs-dev/directories-rs/blob/da65f064a8bb18d790600433fadeed17a54c793a/src/mac.rs#L91-L98

And the Windows impl doesn't change anything:

https://github.com/dirs-dev/directories-rs/blob/da65f064a8bb18d790600433fadeed17a54c793a/src/win.rs#L98-L100

I suppose we could be more strict, but for now I'm just trying to remove the dependency with minimal changes to the functionality.

[YgorSouza]

Could also use the known-folders crate, which has this function and nothing else. But it's still another dependency, which might end up pulling a different version of windows-sys, so I don't know if it's worth it.

[emilk]

Thanks!

Ultimately it would be nice if someone published all this as its own crate to reduce the amount of code in eframe :)

[bircni]

@emilk which part do you want to be extracted?

[emilk]

Basically all the code that was added in this PR :)

[bircni]

Just started a bit
@YgorSouza if you want I'd be happy to get some help via PR or whatever :-)
https://github.com/bircni/file_storage

[Mingun]

Issue tracker should be different in this line:
https://github.com/bircni/file_storage/blob/1fbec8ed8c3d853a99cde7bab33a7f17eaf6bc79/src/os.rs#L73

[bircni]

The question is what to do with the os.rs ?
Put it in the crate too or get it via egui as a dependency

[YgorSouza]

Do we really want to make a new crate just for that? I mean, previously eframe was getting all this code from the directories crate, but the linked issue asked to remove it because the author added an MPL-2.0 dependency that could be replaced by a single line of code, and refuses to remove it. Note that egui accepts the MPL-2.0 license, and there are 5 other dependencies with this license in the lockfile. The suggested alternative was the etcetera crate, which does the same thing as directories, but as it isn't updated often, I figured it would cause duplicated dependencies in the long run (it already uses a different version of windows-sys than winit does, but so does directories), so I just put the code directly in eframe. The only non-trivial bit of code is the roaming_appdata function for Windows, which can be replaced by the known-folders crate as I mentioned above. So if we don't want to have this code in eframe, there are plenty of existing options already: either use etcetera for everything, or use known-folders for the Windows part, or just revert this PR and go back to directories. I feel like rewriting everything in a new crate would just be redundant.