Attached: 1 image
My fellow software engineer,
It's the year 2024.
Please store your #Linux #desktop application configurations ONLY in `$XDG_CONFIG_HOME`.
NOT in `$HOME` or other non-standard or obsolete places.
May #FreeDesktop be your guide.
https://www.freedesktop.org/wiki/Specifications/
#Programming #DevOps #SysAdmin
It makes it insofar better to me that you have the option to change it. You can’t change Mozilla programs to use anything but .mozilla (apart from modifying the source code of course) so for me seeing the folder is at least a way of telling me that the variable is unset.
The better question is which folder is suited the best to store the stuff that goes into $GOPATH
I really didn’t like this either. It’s quite surprising, because the rest of Go tooling is quite nice. Not having a venv, or at least something like pnpm-style node_modules is weird
Maybe Linux should have .local and .roaming folders like Windows. local = only useful on this system, roaming = good to sync across systems. Config would be in .roaming if it’s not machine-specific.
There’s some stuff in~/.config that’s specific to the computer. KDE is a good example - a lot of KDE apps mix config and state in the same file. There’s some solutions for syncing these files, like https://github.com/VorpalBlade/chezmoi_modify_manager which is an addon to Chezmoi that can exclude particular keys when storing an INI-style config file in Git.
I’m sure there’s some config files in there that are entirely specific to the computer. Things like the Wayland per-monitor scaling settings are in there somewhere I think.
There’s also things like data files that you may want to keep in sync across machines. They’re not really configs.
Golang puts shit specifically in
$HOME/go. Not even.go. Just plaingo.Why is it so difficult to follow industry standards
That’s what happens when you don’t set $GOPATH I think
That doesn’t make it better.
It makes it insofar better to me that you have the option to change it. You can’t change Mozilla programs to use anything but .mozilla (apart from modifying the source code of course) so for me seeing the folder is at least a way of telling me that the variable is unset.
The better question is which folder is suited the best to store the stuff that goes into $GOPATH
Just because something is worse, doesn’t make the other thing good. A sane and standard default, as others have mentioned, is a small bar to meet.
Of course, but that’s not the point. There should be a sane default, and there isn’t one
Go pisses me off with that. I separate projects the way I want but go wants every project written in go in one big directory?
I really didn’t like this either. It’s quite surprising, because the rest of Go tooling is quite nice. Not having a venv, or at least something like pnpm-style node_modules is weird
Why would go have a virtual environment or dep tree like node_modules equivalent, it’s not interpreted or dynamically linked.
With modules, dependencies can be vendored.
Obviously it’s not, but you have to download all this shit somewhere before compilation. That’s the whole point
pick one
This post literally links to the leading one.
off the shelf go was too annoying for me
Nowadays I set GOENV_ROOT to an XDG location and use goenv instead.
deleted by creator
What I want in
$HOMEare the following directories:If I’m on a GUI-based environment:
In general:
I’d like everything else to live within something like ~/.local thanks
Maybe Linux should have
.localand.roamingfolders like Windows. local = only useful on this system, roaming = good to sync across systems. Config would be in.roamingif it’s not machine-specific.The only practical difference between Local and Roaming and LocalLow is that developers randomly pick one and dump your game saves in there.
Does
~/.configfit the bill for the second one?There’s some stuff in
~/.configthat’s specific to the computer. KDE is a good example - a lot of KDE apps mix config and state in the same file. There’s some solutions for syncing these files, like https://github.com/VorpalBlade/chezmoi_modify_manager which is an addon to Chezmoi that can exclude particular keys when storing an INI-style config file in Git.I’m sure there’s some config files in there that are entirely specific to the computer. Things like the Wayland per-monitor scaling settings are in there somewhere I think.
There’s also things like data files that you may want to keep in sync across machines. They’re not really configs.
There is a
.localfolder these days.Profile roaming hasn’t been solved aside from NFS mounts. I guess Syncthing might work.
I know
.localexists - My comment was more about.roamingwhich would be nice to exist, but doesn’t currently exist.I’m using Chezmoi to sync some dotfiles, scripts, etc. to a Git repo and that seems to work well enough for me. I’m not syncing much yet, though.