6 ms·

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

by irq-1 3y ago

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 ago
  The 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 ago
    Ok, 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!

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

by irq-1 3y ago

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

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 ago
The 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 ago
  Ok, 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!