- cross-posted to:
- programming@lemmy.ml
- cross-posted to:
- programming@lemmy.ml
Shameless plug: I am the author.
You must log in or register to comment.
Golang puts shit specifically in
$HOME/go. Not even.go. Just plaingo.Why is it so difficult to follow industry standards
Google
following industry standards
pick one
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?
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.
100% agree and I also despise devs who do this on windows, instead of using %appdata% they’re using c:\users\username\.myappisimportantandtotallydeservesthisdir
I wish they used them all, especially
XDG_CACHE_HOMEwhich can become pretty big pretty fast.This would just further complicate things for me. It assumes that 1) the system even has a windowing system/desktop environment or 2) all the installed software is XDG-aware. Most of the time I’m fiddling with headless environments.
The spec doesn’t make those assumptions at all, idk where that’s coming from.
I have headless machines with XDG vars configured and ones without them. XDG compliant software works in either case, but I’m less likely to use a piece of software that clutters my $HOME.
So yes, “XDG” stands for “Cross-Desktop Group” - but I don’t agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don’t set the relevant env vars).
OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn’t on a system that doesn’t have a typical home directory layout or permissions.
YOU’RE NOT MY MOM I’LL DO WHAT I WANT
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.
But what’s the difference? It’ll be in /home anyways and I heard BSD had some issues with something that could be XDG.
To give one example, what if someone wants to have more than one set of options for the same app? That’s something I’ve needed before, and it’s really hard to accomplish if the app always looks in one specific place for its options.
Whatever happened to Linux being all about choice? Do you want that or not?
Are there other relevant standards? The XDG base directory specification has been around for a long time, and is well established.
Maybe your comment wooshed over my head; if so I apologize.
having choices are the opposite of conforming to standards
This standard makes your software’s paths user-configurable, giving users a choice.
And if I don’t agree with how that standard is implemented? I should have the choice to use something else. Isn’t that how everything works?
Well, when software supports this standard, you as a user have a way to not confirm to it by setting the env variables to whatever you want, even per app. So you have two choises, either use it as is or change it.
But if software doesn’t supportthe spec, there is no choise of using it. So ons choise less.
