3 ms·

Thanks, you raise a good point. To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app ap

Thanks, you raise a good point. To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app apart from a line or two to install/import the package. In code, config is accessed in the same way as local environment variables. For example, with python, it's just: $ pip install envkey # in main.py (the entrypoint of your app) import envkey # anywhere else in your code stripe.api_key = os.environ["STRIPE_SECRET_KEY"] If you decide to switch to some other approach based on environment variables, all you need to do is remove the envkey package. Does that help to address your concern at all?

peterwwillis 9y ago
Doesn't really make sense. Why are you importing this package if you're getting the creds via environment? Why wouldn't you just load the creds into the environment with an external tool, and then just run your app, and never have to modify your app in the first place?
- danenania 9y ago
  Importing the package is what sets the config on the environment. If you'd prefer not to modify the app at all, you could also use EnvKey's bash tool, envkey-source: https://github.com/envkey/envkey-source https://github.com/envkey/envkey-source This lets you set the config as OS-level environment variables, and therefore doesn't require adding a library to your app. With an ENVKEY environment variable set, it works like this: $ eval $(envkey-source) $ python >> import os >> os.environ["SOME_API_KEY"]
  - peterwwillis 9y ago
    Using the bash tool is a great solution, and is way less technical debt than adding code to an app. I would have the tool execute apps directly rather than export them to bash, though both are useful.
    - danenania 9y ago
      Great - I'm glad that's a better fit for you :) You can accomplish 'executing an app directly' with a sub-shell like this: $ (eval $(envkey-source) && run-app-command) That way, the variables won't be exported in the parent shell.
ProblemFactory 9y ago
import envkey # Fetches and install environment In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done. The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scripts or tests, or from any other script file at all if a few setup lines are added. People prefer to put all imports at the top of the file, but may want to do something right before or after envkey runs. Imports are not supposed to fail or throw exceptions, unless there is a serious code bug. It would be nicer to have import envkey # No important side-effects envkey.setup() # Can be placed at the appropriate place or similar.
- danenania 9y ago
  Thanks for the feedback. A one-liner to import is more consistent with EnvKey's style (this is how it works in all the libraries), but perhaps it makes sense to expose the loader as a separate package so that you can have more granular control when it's necessary.

peterwwillis 9y ago

Doesn't really make sense. Why are you importing this package if you're getting the creds via environment? Why wouldn't you just load the creds into the environment with an external tool, and then just run your app, and never have to modify your app in the first place?

danenania 9y ago
Importing the package is what sets the config on the environment. If you'd prefer not to modify the app at all, you could also use EnvKey's bash tool, envkey-source: https://github.com/envkey/envkey-source https://github.com/envkey/envkey-source This lets you set the config as OS-level environment variables, and therefore doesn't require adding a library to your app. With an ENVKEY environment variable set, it works like this: $ eval $(envkey-source) $ python >> import os >> os.environ["SOME_API_KEY"]
- peterwwillis 9y ago
  Using the bash tool is a great solution, and is way less technical debt than adding code to an app. I would have the tool execute apps directly rather than export them to bash, though both are useful.
  - danenania 9y ago
    Great - I'm glad that's a better fit for you :) You can accomplish 'executing an app directly' with a sub-shell like this: $ (eval $(envkey-source) && run-app-command) That way, the variables won't be exported in the parent shell.

ProblemFactory 9y ago

import envkey # Fetches and install environment In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done. The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scripts or tests, or from any other script file at all if a few setup lines are added. People prefer to put all imports at the top of the file, but may want to do something right before or after envkey runs. Imports are not supposed to fail or throw exceptions, unless there is a serious code bug. It would be nicer to have import envkey # No important side-effects envkey.setup() # Can be placed at the appropriate place or similar.

danenania 9y ago
Thanks for the feedback. A one-liner to import is more consistent with EnvKey's style (this is how it works in all the libraries), but perhaps it makes sense to expose the loader as a separate package so that you can have more granular control when it's necessary.