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

data_directory() and data_local_directory() are identical. #2212

Closed
gl-yziquel opened this issue Jun 30, 2024 · 3 comments
Closed

data_directory() and data_local_directory() are identical. #2212

gl-yziquel opened this issue Jun 30, 2024 · 3 comments

Comments

@gl-yziquel
Copy link
Contributor

Hi.

As I'm busy making executable justfiles to my own end, they do require some auxiliary files (for templating with tera, in this case). So I've been playing with data_directory() and data_local_directory().

I noticed they both return something like /home/mini-me/.local/share. I would have expected something like /usr/local/share for data_directory().

Haven't looked into it. Can't tell whether just is at fault or if it is the dirs crate that is at fault.

Using just 1.29.1.

@gl-yziquel
Copy link
Contributor Author

I see the following code in the just codebase, in src/function.rs:

    "data_directory" => Nullary(|_| dir("data", dirs::data_dir)),
    "data_local_directory" => Nullary(|_| dir("local data", dirs::data_local_dir)),

It therefore seems more than likely that it is the dirs crate that is at fault.

@gl-yziquel
Copy link
Contributor Author

Well, I looked into it. It seems that the dirs-rs crate always uses the user-space and not the system-wide values for folders.

As such, it does not fit my use case. For instance, my bld executable justfile tool needs to be used by multiple system users. And needs to be system-wide, and not user-space only.

As such, the python platformdirs package provides more sensible values, in my case and use case.

It's no biggie to invoke python from just. So not a big issue. But it is debatable whether just should only provide support for userspace folders.

In fact, I'd suggest the following kind of nomenclature:

  • executable_system_directory or data_system_directory for the system wide folders.
  • executable_directory or data_directory for the userspace wide folders.

The rationale being that for things to work out of the box, it's better to have short names, and, in this case, there is no access rights issues for the short names. The longer names need an explicit decision (to type longer) stuff, and this is as such a warning that more pain is in order: no access rights for system folders by default.

Any way. This is a design decision to make.

@casey
Copy link
Owner

casey commented Jun 30, 2024

If /usr/local/share isn't the folder you want, I don't think there's a simple, standards-based way to find an alternative. I.e., on systems without /usr/local/share, but some other, similar directory, I'm not sure how to find that directory, so there's no way to provide a function that returns it. So I think your best bet is to use /usr/local/share directly.

@casey casey closed this as completed Jun 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants