Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the directories dependency #4904

Merged
merged 5 commits into from
Sep 1, 2024

Conversation

YgorSouza
Copy link
Contributor

@YgorSouza YgorSouza commented Aug 2, 2024

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).

@bircni
Copy link
Contributor

bircni commented Aug 2, 2024

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

@YgorSouza
Copy link
Contributor Author

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.

@@ -58,12 +58,15 @@ android-native-activity = ["egui-winit/android-native-activity"]
## If you plan on specifying your own fonts you may disable this feature.
default_fonts = ["egui/default_fonts"]

## Enable the directories dependency for a more precise file path for the persistence feature.
## Not needed if you provide your own path, or if the simpler default path resolvers are good enough.
directories = ["dep:directories"]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a default feature to avoid breaking changes?

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 emilk added the eframe Relates to epi and eframe label Aug 26, 2024
p.join(
app_id
.to_lowercase()
.replace(|c: char| c.is_ascii_whitespace(), ""),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_-]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

It is now possible to enable the persistence feature without depending
on the directories crate, for uses who wish to provide their own paths
from another source.

When the directories feature is not enabled, a simpler naive
approximation of its output is used, which covers the most common target
systems.
It was wrong in the documentation as well.
@YgorSouza YgorSouza force-pushed the persistence-without-directories branch from 8f47322 to e78a47c Compare August 27, 2024 17:47
@YgorSouza YgorSouza force-pushed the persistence-without-directories branch from de3af89 to 8bd8072 Compare August 28, 2024 06:45
@YgorSouza YgorSouza changed the title Decouple directories from persistence in eframe Remove the directories dependency Aug 28, 2024
}
unsafe {
let mut path = ptr::null_mut();
match SHGetKnownFolderPath(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

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

@emilk emilk added the dependencies Pull requests that update a dependency file label Sep 1, 2024
@emilk emilk changed the title Remove the directories dependency Remove the directories dependency Sep 1, 2024
@emilk emilk merged commit edea5a4 into emilk:master Sep 1, 2024
21 checks passed
@bircni
Copy link
Contributor

bircni commented Sep 1, 2024

@emilk which part do you want to be extracted?

@emilk
Copy link
Owner

emilk commented Sep 2, 2024

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

@bircni
Copy link
Contributor

bircni commented Sep 3, 2024

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
Copy link
Contributor

Mingun commented Sep 3, 2024

@bircni
Copy link
Contributor

bircni commented Sep 4, 2024

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
Copy link
Contributor Author

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.

486c pushed a commit to 486c/egui that referenced this pull request Oct 9, 2024
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 <emilk#4884>
* [x] I have followed the instructions in the PR template
hacknus pushed a commit to hacknus/egui that referenced this pull request Oct 30, 2024
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 <emilk#4884>
* [x] I have followed the instructions in the PR template
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file eframe Relates to epi and eframe
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replace directories dependency
4 participants