When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature.
dir, err := os.Getenv("CREDENTIALS_DIRECTORY")
cred, err := os.ReadFile(filepath.Join(dir, "name"))
I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
That'll also let you avoid writing the `if err != nil { return fmt.Errorf("context string something: %w", err) }` boilerplate again and again too (since you can just write '.context("context")?' each time).
If you're using Go, you're not supposed to build abstractions, small packages, or any sorta clever or good code. And be really careful using generics.
If you want to write abstractions, you're supposed to use a different language. Those are the rules.
Really? I thought the point of the environment variable was it was the same, and the directory it pointed to differed depending on the service type.
I'd love a reference since at least for every systemd version I've used, you're wrong.
> Proper error handling and graceful fallback
That's application specific, so it can't really fit in a generic library well.
I must've had it confused with StateDirectory[0]. Thank you for pointing my mistake out. That does make the library a bit less useful.
[0]: https://www.freedesktop.org/software/systemd/man/latest/syst... Table 2
systemd-run -p StateDirectory=test -t sh -c 'echo $STATE_DIRECTORY'
The library the person linked is to deal with systemd credentials in go.
The two lines of code I wrote are the same, and in fact are effectively 100% of the code in the library.