Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion about environment variables in libraries #101

Open
bruce-ricard opened this issue Aug 15, 2020 · 0 comments
Open

Discussion about environment variables in libraries #101

bruce-ricard opened this issue Aug 15, 2020 · 0 comments

Comments

@bruce-ricard
Copy link

The README states

PG'OCaml uses environment variables (or in-code parameters, which are [ill advised] (https://hackernoon.com/how-to-use-environment-variables-keep-your-secret-keys-safe-secure-8b1a7877d69c)) to connect to your database both at compile-time and at runtime.

First of all, I agree very much with the desire not to write any credential to a configuration file on disk. I like very much the idea of passing your credentials to your server through environment variables.
Now, I would say that is NOT the job of a library to do that. I don't want my libraries to dictate the way I pass in my configuration. What about name clashing with another library? Some Peter Gray creates a library and makes it configurable through the environment variable PGUSER and we are screwed.

IMHO it is the responsibility of the developer of the "main" to decide how configuration is going to be passed to the libraries. I personally would like to read environment variables and pass them to the pgocaml library.
It also makes the code a lot easier to understand when I can see what is being passed to the library, for debugging purposes. I don't want to have to look at the library's code to understand what value is being used for the password.

My opinions are always loosely held, please feel free to share your thoughts if you disagree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant