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

Proper home support on Linux #66

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

iacore
Copy link

@iacore iacore commented Aug 16, 2022

I'm not sure how other posix OS will handle this. On Linux ~/.local/share/zig is the proper path to use.

@marler8997
Copy link
Owner

I'd be in favor of a build option to change the default install directory.

For me I like my compilers to go in ~/zig. It makes it quick/easy to type out their paths for grep purposes. Assuming we add a build option to change the default install directory, that leaves us with what the default should be. What's the pros/cons of moving the default from ~/zig to ~/.local/share/zig?

P.S. the purpose of the mkdir log is to make it clear what zigup is doing to end users. Currently it's doing the equivalent of mkdir -p so logging it every time is purposeful. It makes it clear that zigup will always create that directory if it doesn't exist, removing the log when it doesn't need to be created means the user won't know this behavior until they actually delete the directory.

@iacore
Copy link
Author

iacore commented Aug 17, 2022

What's the pros/cons of moving the default from ~/zig to ~/.local/share/zig?

It's a tradition of the UNIX world. It's considered impolite to mess with one's home directory without notice. I remembered backlash back when Go did the same thing. In Go, GOPATH can be set to ~/.local/share/go.

I'd say for Linux, ~/.local/share/zigup is the better default choice. I don't know much about BSDs, since .local/share seems to be a Free Desktop (XDG) thing.

FYI, rustup use ~/.rustup/.

It makes it clear that zigup will always create that directory if it doesn't exist, removing the log when it doesn't need to be created means the user won't know this behavior until they actually delete the directory.

I doubt most user care about that. I use zigup to update zig and that's it.

@resolritter
Copy link

~/.zigup would be more in line with what I have seen in other tools. Just glancing at my home directory, I have

  • ~/.cargo and ~/.rustup for Rust
  • ~/.gem and ~/.rvm for Ruby
  • ~/.yarn, ~/.npm, ~/.nvm for Node.js
  • ~/.pyenv for Python
  • ~/.gradle for Java
  • ~/.choosenim and ~/.nimble for Nim

Clearly the pattern there is . + TOOL_NAME. It seems to be followed pretty consistently across the many different languages and tools I have installed.

~/.local/share/zigup seems proper, as $HOME/.local/share is related to the XDG Base Directory Specification. However, one might argue that this location is too Linux-specific. My guess is that ~/.zigup would be alright for both Linux and macOS, so it could be preferred because of that.

@dnut
Copy link

dnut commented Oct 13, 2023

Creating a zig folder in home is unacceptable. Applications should never clutter a user's home folder. I would prefer to completely avoid this tool rather than create ~/zig on my computer. I compiled a version with this patch to solve the problem.

~/.local/share/zigup is the correct answer. I would be willing to live with ~/.zigup if it's the only option to get away from ~/zig, since at least it's a hidden folder. But it is definitely not ideal because it still clutters the user's global namespace.

The XDG base directory specification is the most widely accepted and well-documented answer to this question. Placing direct dotfiles in home is typically viewed as an incorrect legacy approach by the Linux community. The XDG standard is also not Linux-specific and is applicable to any unix-like system.

If you want to cater to macOS, the correct location would be /Users/<username>/Library/Application Support/zigup. The official guidance from Apple is clear that applications should not store anything directly in the user's home folder.

macOS File System Programming Guide

File System Basics:

/Users ... for storing user documents and media only. Apps must not write files to the preceding directories unless explicitly directed to do so by the user. The sole exception to this rule is the Library directory, which apps may use to store data files needed to support the current user.

macOS Library Directory Details:

The Library directories are where the system and your code store all of their related data and resources... Application Support Contains all app-specific data and support files. These are the files that your app creates and manages on behalf of the user and can include files that contain user data.

Where to Put Files:

Don’t Pollute User Space

It is important to remember that the user domain (/Users) is intended for files created by the user. With the exception of the ~/Library directory, your application should never install files into the user’s home directory. In particular, you should never install files into a user’s Documents directory or into the /Users/Shared directory. These directories should only be modified by the user.

Even if your application provides clip art or sample files that the user would normally manipulate, you should place those files in either the local or user’s Library/Application Support directory by default. The user can move or copy files from this directory as desired. If you are concerned about the user finding these files, you should include a way for the user to browse or access them directly from your application’s user interface.

@dweiller
Copy link
Contributor

I've not personally used it, but I know a number of zig projects (e.g. zls) use https://github.com/ziglibs/known-folders for cross-platform support for paths to config/data folders.

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

Successfully merging this pull request may close these issues.

5 participants