3 ms·

> Curious what features you use beyond this. There’s plenty of outstanding questions. Is the export required? Can variables reference other variables? Can v

by koolba 3y ago

> Curious what features you use beyond this. There’s plenty of outstanding questions. Is the export required? Can variables reference other variables? Can variables reference existing variables in the environment? Can you use other forms of expressions? Can you set overridable defaults for values?

sonthonax 3y ago
It's a shell script that should be executable by any UNIX shell. Parsing it (rather than executing it) is why those questions are raised.
- claytongulick 3y ago
  In the nodejs community it's normally used via dotenv. So, yes it's parsed and a valid use case.
sergiotapia 3y ago
I've never used/needed those features from my .env files that's why I'm asking for use cases. Are you saying you use those kinds of features in python_dotenv? I'm asking btw, no snark.
- SOLAR_FIELDS 3y ago
  I use them in python_dotenv for declaring environments that I use to provision infrastructure, as an example: Example, where we have: env_type="dev" env_name="myappenv" primary_subnet_pod="${env_type}-${env_name}-gke-pod-subnet" primary_subnet_service="${env_type}-${env_name}-gke-service-subnet" Which I then might want to use further down, override with defaults, etc and so forth. It strikes a decent balance in that it's a bit more powerful than a static .env file, but doesn't require you to go full-on templating language with Jinja and the like. It's also cross-platform enough in that you could throw a .env in somewhere and expect most languages to have a client library to parse and load it into env. If your use-case is right in that sweet spot it's a pretty good tool. But the behavior, as noted, isn't specced so I can't trust go_dotenv or rust_dotenv or whatever other library to treat it the same way. Interestingly, in practice, it seems like the Node lib is the canonical version that inspired these other ones so in a way it serves as some sort of unofficial spec. It's not something I would write production grade code trusting the unofficial spec on though.

by koolba 3y ago

sonthonax 3y ago

It's a shell script that should be executable by any UNIX shell. Parsing it (rather than executing it) is why those questions are raised.

claytongulick 3y ago
In the nodejs community it's normally used via dotenv. So, yes it's parsed and a valid use case.

sergiotapia 3y ago

I've never used/needed those features from my .env files that's why I'm asking for use cases. Are you saying you use those kinds of features in python_dotenv? I'm asking btw, no snark.

SOLAR_FIELDS 3y ago
I use them in python_dotenv for declaring environments that I use to provision infrastructure, as an example: Example, where we have: env_type="dev" env_name="myappenv" primary_subnet_pod="${env_type}-${env_name}-gke-pod-subnet" primary_subnet_service="${env_type}-${env_name}-gke-service-subnet" Which I then might want to use further down, override with defaults, etc and so forth. It strikes a decent balance in that it's a bit more powerful than a static .env file, but doesn't require you to go full-on templating language with Jinja and the like. It's also cross-platform enough in that you could throw a .env in somewhere and expect most languages to have a client library to parse and load it into env. If your use-case is right in that sweet spot it's a pretty good tool. But the behavior, as noted, isn't specced so I can't trust go_dotenv or rust_dotenv or whatever other library to treat it the same way. Interestingly, in practice, it seems like the Node lib is the canonical version that inspired these other ones so in a way it serves as some sort of unofficial spec. It's not something I would write production grade code trusting the unofficial spec on though.