Change default install location to zigup's directory

[marler8997]

The current install location for zigup is ~/bin on posix systems. The reason for this is that

• It's likely writeable by the current user
• It's a common location that is added to the users PATH

However, another default location could be the path to the zigup binary itself. This solves the PATH issue because it means zig will be reachable in the same manner that the user is calling zigup. For example, if the user installed zigup to a location that is in the PATH, then zig will be available in the same PATH entry. If zigup is not availabe in PATH, then maybe the user didn't want it to be.

Note that the default install location doesn't preclude other solutions. For example, this default solution is not viable for the "Nix Package Manager" because zigup would be installed to its own directory (which should be readonly). In this case I expect the Nix expression to create the zigup and configure a different default install location, perhaps ~/bin. It seems fine to change the default install location for versions of zigup that are installed by package managers and a version that is meant to be a standalone executable installed by the user.

[dropwhile]

$HOME/.local/ is a pretty common local home dir location for things these days too. As an example, it is commonly used in python land with pip install --user installing bins to $HOME/.local/bin and libs to $HOME/.local/lib.

XDG_DATA_HOME is by default $HOME/.local/share, as well.
ref: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[dropwhile]

Another example: asdf-zig uses asdf and supports a "wherever it is installed" kind of thing.
note: I tossed my install in $HOME/.local/asdf, and it was working ok until I migrated to an macbook m1 -- as there is no supported zig build available on the downloads page yet for m1 macs.

[ghost]

Would be nice if this respected XDG spec and put it in ~/.local instead. Polluting the home folder is generally considered a bad move.

[g-w1]

I have a fork that does this.

[rutgerbrf]

Both rustup and ghcup install in ~/.rustup and ~/.ghcup respectively. That makes ~/.zigup seem like an intuitive location (for users which have used rustup or ghcup).

[ghost]

Just because they do it doesn't mean zigup should. rustup even has piping a shellscript into curl straight from the internet as an installation method, which is bad practice.

Completely ignoring XDG spec for new software to me seems silly, hardcording paths is simply bad design no matter how you cut it.

[rutgerbrf]

Just because they do it doesn't mean zigup should. rustup even has piping a shellscript into curl straight from the internet as an installation method, which is bad practice.

Nope. However, as a user, I'm willing to do that (for once) for the added convenience.
What installation method do you prefer?

Completely ignoring XDG spec for new software to me seems silly, hardcording paths is simply bad design no matter how you cut it.

I agree. Just did some googling and came across this: rust-lang/rustup#247
ghcup has an env called GHCUP_USE_XDG_DIRS which seems a bit weird to me.
I think it would be best if zigup would use the platform's standard installation dir by default, and allow the user to customize it to whatever place they prefer.

Edit: rustup also has this issue: rust-lang/rustup#2418

[ghost]

To me checking if the env vars for XDG exist first, honoring that and if they don't then checking if .local exists in the user's home folder seem to be better than just throwing everything in the home folder straight away. Barring that I guess installing in $HOME anyway is the best (only) solution.

It's a difficult choice to go back once every script or build system relies on certain stuff being available in hardcoded locations rather than checking for environment variables first. It's been a long running issue for multiple software, even Firefox (.mozilla in home) has this going on for 17 years! https://bugzilla.mozilla.org/show_bug.cgi?id=259356

[rutgerbrf]

Sounds good, there's still Windows with AppData though (seems like zigup doesn't support Windows yet anyways)

[marler8997]

Now that zigup is finally working on Windows (thanks to the zarc project for extracting zip files) and we have prebuilt binaries, I thought about this issue for Windows. For Windows I'm going to go with what I originally proposed which is to install the zig.bat file that links to the actual compiler in the same directory as zigup.exe. This provides the user full control over where to install the zig.bat file because it will always get installed to the same directory as zigup.exe. To change it, the user can move zigup.exe. That being said, the directory where zig.bat goes, and the directory where zigup downloads/installs the compilers (the "install directory") don't necessarily need to be the same. To change that, the current solution would be to wrap zigup in a batch file and override the install directory via --install-dir.

Having said this, I'm thinking about removing the --path-link command-line option and always having it derived from the zigup.exe location, at least on Windows. This would mean that for the unit tests, instead of adding --path-link scratch\zig.bat to the zigup command-line, it would just copy zigup.exe to the scratch directory and call that one. I'm not sure if we want to do the same thing on linux yet, but I'll try to remember to consider it and I might go that way as well (at least for the "zig link", not for the install directory).

[marler8997]

I feel like this issue has come to a resolution.

On windows the install directory is a directory named "zig" that lives in the same directory as zigup.exe. For all other platforms, it's $HOME/zig. At this point I'm happy with these being the default.

For non-default cases we can add a build option to change the default directory to something else. I'll add this if anyone indicates they would like this and this covers all the non-default cases I can think of.