data_directory() and data_local_directory() are identical. about just HOT 3 CLOSED

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.

from just.

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.

from just.

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.

from just.