3 ms·
Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries. One is envkey-sou
by danenania 3y ago
Hmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries.
One is envkey-source (https://docs-v2.envkey.com/docs/envkey-source https://docs-v2.envkey.com/docs/envkey-source), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this:
# some-command runs with EnvKey vars in its environment
$ envkey-source -- ./some-command
Or like this:
# EnvKey vars are set in current shell
$ eval $(envkey-source)
$ echo $SOME_ENVKEY_VAR
And second, envkey-source is also wrapped by our language-specific SDKs, including one for Go: https://github.com/envkey/envkey/tree/main/public/sdks/languages-and-frameworks/go/envkeygo https://github.com/envkey/envkey/tree/main/public/sdks/langu...
It allows you to integrate with a Go project like this:
// main.go
import (
"os"
_ "github.com/envkey/envkeygo/v2"
)
// assuming you have GITHUB_TOKEN set in EnvKey
token := os.Getenv("GITHUB_TOKEN") // this will stay in sync
We're planning to do a docs-improvement pass soon so I'm very interested in how we could clear up any confusing aspects of how the different pieces fit together.
- irq-1 3y agoThe second project; it only does caching of the keys. It's a big advantage to use your software without any SDK or client code. You should make it clear that it's optional.
- danenania 3y agoOk, understood. The purpose is not so much caching as setting the vars in the environment so they can be accessed in a standardized way that is compatible with dotenv, 12 factor apps, etc. But yes, you could also say they’re being cached. We do try to mention in the docs for each SDK that envkey-source can be used from the shell instead, but I’m sure we can make it clearer. Thanks again!