- cross-posted to:
- [email protected]
Golang puts shit specifically in
$HOME/go
. Not even.go
. Just plaingo
.Why is it so difficult to follow industry standards
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
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
Google
following industry standards
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.
Shout out to xdg-ninja - it’ll find files that are in your home and suggest how to configure the app to use XDG instead. https://github.com/b3nj5m1n/xdg-ninja
Strange that some apps allow configuring it rather than just doing it automatically…
That’s the usual open source way. The config probably came later so they just added the option without changing the default because that would break backward compatibility.
And there would be too much boring work to build a migration.
After running it and properly configure the paths I once again came to the conclusion: I fucking hate Google.
Thanks, I hadn’t heard of that. Time to add a few hundred lines to my dotfiles :)
100% agree and I also despise devs who do this on windows, instead of using %appdata% they’re using c:\users\username\.myappisimportantandtotallydeservesthisdir
Not to mention - this isn’t necessarily the correct place for Windows anyway. That is exactly why they standardized stuff around Vista.
Plus - what about apps that store an ungodly amount data in there? Personally, I only keep the OS and basic app data (such as configs and cache) on the partition and nothing else.
Then something like Minecraft comes along and it’s like “humpty dumpty I’m crapping a lumpty” and stores all its data in “.minecraft” right there in your user directory.
Then you gotta symlink stuff around and it becomes a mess…
I have to use a separate Documents folder for my actual documents lol
I think that also causes issues for roaming profiles and folder redirection. If roaming is turned on then everything in the %appdata%\roaming folder is synced to a server. %AppData%\Local is not. So if your app is using %AppData%\Roaming for temporary data then you are causing a whole bunch on unnecessary IO. Same for using Documents since that if often synced.
To be fair here, appdata is technically a hidden folder and there are lots of reasons an app would want it’s data accessable by the user.
Yes but then just spam the documents folder like anyone else, don’t hoard the home root for no reason except that is a lazy cross platform port
Where did i read this… basically, the .file being hidden being a bug in the early unix filesystem, which got misused to hide configuration files.
Offenders despite XDG-variables set and with no workaround:
- .android: hardcoded in adb and i guess something in mtp too
- .pki: some tool/library Firefox and Chromium sometimes use.
- .steam: yes, that
Shameless flex
I regret checking this
This is probably a dumb question, but what program is that?
Looks like thunar (default file manager on xfce)
thunar (and the smaller window is the xfce4-terminal).
Lol, the minimalist window decoration had me thinking you were running a terminal inside of the home directory of your file manager. :D
I’ve seen weirder things.
Honestly, that’s what I thought too, and wanted to check that out
Whoa I’m a stickler for getting as much as I can out but even I have .zshenv and some other too hard to figure out things in there. How’d you manage a total wipeout?
zsh is actually easy and it is detailed in the archwiki
You have to set
$ZDOTDIR
in/etc/zsh/zshenv
and iirc that was the only location that required root to edit.For the rest of stuff, here is how I fix steam for example and you can check the rest of my dotfiles for how I configured zsh and all of that.
Although I haven’t updated them, I still had a
.local
directory back then, it was 1 week ago that I changed.local
forLocal
and that let to an issue with distrobox which I made a PR fixing it that’s still open though.That’s awesome!
ls Volatile
It’s empty lol, it’s a directory on tmpfs that i use to build programs and similar stuff to not be hammering my ssd with unnecessary writes.
I have
$XDG_CACHE_HOME
in tmp as well and I moved the mesa sharer caches to$XDG_STATE_HOME
as that’s really the only thing so far I’ve needed to preserve.tmpfs (…) to build programs (…) to not be hammering my ssd with unnecessary writes
Sounds useful. How did you setup the directory?
Running
df
tells me “tmpfs” is mounted on /run. If I build in that that directory then would it be stored in RAM, or do I need to do something else?I have /tmp in my fstab with these mount options.
tmpfs /tmp tmpfs rw,noatime,size=20G 0 0
And the rest of the setup is done in my zprofile
I think I should be able to get this working following your zprofile file. Thanks!
I wish they used them all, especially
XDG_CACHE_HOME
which can become pretty big pretty fast.And i wish there was a separate XDG_LOG_HOME or $HOME/.local/log, with logrotate preconfigured to look there.
Or
$HOME/.var/log
.
My fellow FOSS users, patches are welcome.
YOU’RE NOT MY MOM I’LL DO WHAT I WANT
BRB, putting in a PR to make /etc mode 1777 by default.
I didn’t know about this (and thankfully, haven’t written anything public). I’ve been trying to fix an install script for an OSS project that doesn’t work on immutable distros, and using the XDG Base Directory specs might just be the panacea I was looking for!
yes please!
vim now has an option to put the .vim folder in ~/.config; though I’m not sure if the default plugin/package & syntax folders can be set under ~/.local/share.
You can also just use neovim instead, among other improvements, it’s configs are in the xdg dirs
deleted by creator
there’s no place like 127.0.0.1
there’s no place like XDG_CONFIG_HOME.
Probably half the entries in that list are not GUI apps, and XDG doesn’t apply (though some still support it). For some others there (like emacs) XDG is used if it exists.
What makes you think XDG doesn’t apply to non GUI apps?
It’s already in the name - XDG stands for X Desktop Group (nowadays freedesktop), which works on interoperability for desktop environments. In a pure shell environment (or even if you’re not running a full desktop) none of the XDG variables are defined, and especially in shell environments the default fallbacks specified by XDG are not necessarily what the operator would expect.
That name is decades old. XDG stands for “Cross Desktop Group”.
A “pure” X environment (e.g.
startx xterm
) also doesn’t define those variables, but many desktop environments do, just like many shell configurations do.
XDG doesn’t apply for CLI apps? About half of dirs I still have cluttering my home are GUI apps whose devs refuse to follow the specification, while I see less friction from CLI/TUI devs, since they’re the ones actually seeing these hidden locations.