Use data dir instead of home dir for dioxus-related data

[Andrew15-5]

I don't want Dioxus to become yet another app that will pollute my home dir. XDG Base Directory Specification exists for a reason.

Currently, I'm not sure if it's better to move it into a cache dir. Typst packages are located in the cache dir. If they don't exist they are downloaded. This is exactly what dx does, but with binaries.

[jkelleyrtp]

I want to match where cargo, rustup, vscode, android, bun, deno etc place their configuration files and tools. It's nicer that dx places its tools and configurations in a similar folder. While 0.7 doesn't contain many of these files, we do want to place things like the global configuration and eventually dependency caching into this folder.

I don't exactly know how to specify this, but maybe you have more expertise here?

[Andrew15-5]

I want to match where cargo, rustup

So you want DIOXUS_HOME?

I don't exactly know how to specify this, but maybe you have more expertise here?

Thanks for glazing. I do, I almost completely cleaned my home dir¹ with a bunch of env vars set. Here is some of what I have now in this regard:

({config, ...}: with config.xdg; rec {
  home.file = with home.sessionVariables; {
    "${GOPATH}/.keep".text = "";
    "${WGETRC}".text = ''hsts-file = "${cacheHome}/wget-hsts"'';
  };
  home.sessionVariables = rec {
    ADB_VENDOR_KEYS = "${dataHome}/android";

    # Home/config paths.
    CARGO_HOME = "${dataHome}/cargo";
    GOPATH = "${dataHome}/go/packages";
    KERAS_HOME = "${dataHome}/keras";
    MAMBA_ROOT_PREFIX = "${dataHome}/micromamba";
    OLLAMA_MODELS = "${dataHome}/ollama/models";
    PNPM_HOME = "${dataHome}/pnpm";
    RUSTUP_HOME = "${dataHome}/rustup"; # Not needed with fenix.
    TEXMFHOME="${dataHome}/texmf";
    TEXMFVAR="${cacheHome}/texlive/texmf-var";
    TEXMFCONFIG="${configHome}/texlive/texmf-config";
    WEKA_HOME = "${dataHome}/weka";
    WGETRC = "${configHome}/wgetrc";

    PATH = "${PNPM_HOME}:${GOPATH}/bin:${CARGO_HOME}/bin:$PATH";

    NODE_REPL_HISTORY = "${cacheHome}/node_history";
    PYTHON_HISTORY = "${cacheHome}/python_history";
  };
})

{
  home.sessionVariables = {
    NPM_CONFIG_GLOBALCONFIG = "${config.xdg.configHome}/npm/npmrc";
  };
  xdg.configFile."npm/npmrc".text = ''
    cache = ${config.xdg.cacheHome}/npm
  '';
}

Just stuff that accumulates. It's better to have it all set, so that if ever need to use some of the programs again, it will not start polluting my home dir again. wget, npm, and go are a bit picky and not as straightforward, but the majority are all alike.

While 0.7 doesn't contain many of these files, we do want to place things like the global configuration and eventually dependency caching into this folder.

You are describing at least 3 things: cache, config, data. So Dioxus should use XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME, respectively. The fact that other tools don't do it means that they are not XDG home dir spec compliant, which is bad. I have much more programs that I actually use, that are not in the code snippets, meaning that they don't need env var shenanigans, they just work as expected². dirs crate supports XDG home dir spec, so you can keep using it. I don't think adding DIOXUS_HOME to the mix will go well. You would have to write priority logic between this var and what dirs crate can already offer.

For config specifically, I remember about https://crates.io/crates/confy from https://github.com/astrale-sharp/typstfmt. Might be good, though it will probably add one or three dependencies.

Footnotes

1. For a few programs left I do intend on at least patching them locally myself, because not sure if I can or if it's possible to merge it upstream. Though I need actual free time and not much to do, to patch them. ↩

2. Flatpak, Firefox, Thunderbird, MEGA, KNIME, OpenSSH are all still the baddies. You can look at a big list of XDG support at https://wiki.archlinux.org/title/XDG_Base_Directory#Support. Firefox and Thunderbird will have support eventually, since they had quite a few updates in https://bugzilla.mozilla.org/show_bug.cgi?id=259356 and related issues not that long ago, but not right now. ↩

[jkelleyrtp]

The fact that other tools don't do it means that they are not XDG home dir spec compliant, which is bad...

I think the reality is that XDG is just one standard in a sea of platforms with their own inconsistencies. The goal here is to create one folder that we put everything into that you can just delete when you want it gone. If you want to inspect what we download, it's obvious to navigate there and poke around. If you want to swap the binaries we use with your own, that should be easy too. We want to store the user's config there too, so you should be able to easily edit it.

It sounds like we need a DIOXUS_HOME - which should be fine and easy to wire up. We always reference this particular folder through the dioxus_home_dir function. In there we can just use DIOXUS_HOME if it's set.

---

edit: the name we use should be DX_HOME instead of DIOXUS_HOME. I want to keep our branding for the CLI tool to be mostly DX since we want to spin out the CLI into a standalone tool

[Andrew15-5]

I think the reality is that XDG is just one standard in a sea of platforms with their own inconsistencies. The goal here is to create one folder that we put everything into that you can just delete when you want it gone. If you want to inspect what we download, it's obvious to navigate there and poke around. If you want to swap the binaries we use with your own, that should be easy too. We want to store the user's config there too, so you should be able to easily edit it.

You miss out the fact that you can, and if you do backups, you are saving XDG_CONFIG_HOME as this contains (ideally) ALL the configs from all the programs you use. And ONLY configs, which makes it very simple to save all with one command, and* it will keep your backup small in size, as configs are almost always just text files that are small and very compressible. If I want to preserve dx config, I can just do the same. However, with DX_HOME (and other tools that put everything in one place), I have to make an exception not only with how I back it up (backing up just a specific file in that directory, or removing all other files and backing up a directory with one file), but also with how I restore it. I need to unarchive/copy into XDG_CONFIG_HOME, but also handle DX_HOME separately. And this adds up for each *_HOME env var. XDG Home Directory Specification is a great standard and is very well known if you use and learn about Linux bit by bit.

that you can just delete when you want it gone

If I want to suddenly and fully stop using dx/Dioxus, then sure, but I don't think that this is how it works. You might want to clean your cache because of some corruption or to save up disk space. Using rm -rf "$XDG_CACHE_HOME/dx" (which is usually just simply rm -rf ~/.cache/dx) will do the trick. And the cool part is that your dx configuration is preserved. XDG provides flexibility like that.

It sounds like we need a DIOXUS_HOME - which should be fine and easy to wire up. We always reference this particular folder through the dioxus_home_dir function.

It's easy, but the *_HOME vs. XDG issue should be discussed first.

In there we can just use DIOXUS_HOME if it's set.

And if it's not set, what would it be? If you absolutely have to have one directory and will not change your mind, then it would be great to put it in XDG_DATA_HOME/dx, as data stuff can become pretty large, as the case with cargo, rustup, pnpm. This is where I store all the "all in one place" program data (go, cargo, keras, mamba, rustup, weka, etc.). Polluting home dir is just bad, as it not only gets literally dirty (a lot of random stuff, that you might not even know where it comes from, e.g., .var from flatpak), but also makes it much harder to navigate/find the thing you were looking for in your home directory.

[jkelleyrtp]

Made some opinionated changes for mac and windows, but am leaving linux to the data_dir with a fallback to home_dir.

We likely won't respect the full XDG spec (separating config, state, cache, etc).

Also, there's a new DX_HOME var you can set.

I also changed the directory from .dioxus to .dx to match the same dir that the install.sh script downloads dx into.

[Andrew15-5]

Mmmmm... The logical fallback would be ~/.local/share, but I'm glad that at least explicit XDG_DATA_HOME is respected (hence the XDG base dir spec users should be happy). I guess that's the absolute minimum that I can agree on/live with. Actually, it's nice to have DX_HOME as a "fallback", since someone might think that the "everything" dx dir should be in XDG_CACHE_HOME dir or something, so they just use that env var to override it.
Thanks for the compromise.