[Pre-ANN/RFC] XDG.jl: A cross platform implementation of the XDG Directory Spec

Package Announcements
,
21

If you want to introduce the Dirs module only to have it shorter than StandardDirectories, it feels somewhat artificial, and using import StandardDirectories as XDG or import StandardDirectories as Dirs is an alternative.

Like it was mentioned, short package names with cryptic letters are generally not great, but I like XDG here, as afaict it’s much more known that its non-abbreviated form (and CrossDesktopGroup would be an horrible package name here), and any other name will not make me understand what this package does better than just XDG. And if I’m looking for this functionality, i would naturally search something like “julia XDG”.

The fact that this package doesn’t serve only a niche scientific discipline makes it even more acceptable to use a short name. Short names are precious, but only if they can be given to packages when they fit the name obviously, as is the case here I think.

2 Likes
22

Arguably this is bikeshedding, but I personally don’t like regretting naming decisions.

An alternative would be to export functions with prefixes, such as xdg_user_config() ?
This is short, and separates the package name from the API
(since we can’t do something like using XDGPaths as XDG).

23

Hmm, I feel like ?.User.config() is much nicer, particularly considering the counterpart ?.System.config() etc.

3 Likes
24

I feel like ?.User.config() is much nicer, particularly considering the counterpart ?.System.config()

That would be xdg_system_config(), which would be as discoverable,
and in my eyes more readable. Maybe it’s cultural, or I’m missing something.

Others seem to favor your proposal, and you’re doing great, so please don’t be disturbed
and pick anything you like !

25

The rumination continues, BaseDirs is currently in the lead.

26

I want to say that I just looked though the docs, and it looks to me like you have done really good and thurough work, both in implementation and documentation. Thank you!

1 Like
27

Hi! Could this package help putting Julia scripts in the PATH? I guess it can offer a bin function similar to the config one for that. Cheers

28

Let me know if this example answers your question :slight_smile:

julia> jexec = BaseDirs.User.bin("jl-hello-world")
"/home/tec/.local/bin/jl-hello-world"

julia> write(BaseDirs.User.bin("jl-hello-world"), 
       "#!/usr/bin/env -S julia --startup-file=no\n\
        println(\"Hello world!\")\n")
66

julia> chmod(jexec, 0o755)
"/home/tec/.local/bin/jl-hello-world"

julia> run(`jl-hello-world`)
Hello world!
Process(`jl-hello-world`, ProcessExited(0))

julia> rm(jexec)
3 Likes
29

Prompted by this question, I’m considering making create=true also set executability with bin, which would reduce the earlier example to:

julia> write(BaseDirs.User.bin("jl-hello-world", create=true),
             "#!/usr/bin/env -S julia --startup-file=no\n\
              println(\"Hello world!\")\n")

julia> run(`jl-hello-world`)
Hello world!
Process(`jl-hello-world`, ProcessExited(0))
1 Like
30

Oh! That is awesome! :smiley:

31

In a bit (once General merges the PR) v1.1 will be released, which just adds the “make created bin files executable” behaviour discussed above, and removes the two sources of compilation at load-time.

3 Likes