I use a python library called python_dotenv, which like the article describes, loads environment variables from a .env file. My use cases are for just tiny personal projects, but, I do like how the process is the same on my laptop and my web host. If i were to use some specific technology with digital ocean, I would still need to do something for when I'm building this stuff locally.
Generally speaking the only thing I'm holding in my .env file is the Django secret key, and the debug flag, so, pretty limited use case, but works well I think. I manually create the .env file when setting up my site, so none of it goes into any repos.
In devenc, you shouldnt need a ton of secrets anyhow. Each dev should have many of their own unique "secret" bits.
Being able to roatate a secret in devenv & have things keep working is early intermediate maturity model, but I'd wager most orgs have nothing.
This isn't a dotenv problem, isn't a security problem. It's that no one has soaked time or your department stoggily refuses to try out the really good Ansible or whatnot env to set your various microservices up for local dev.
I used to use this package to avoid having to use ENV variables for everything (it pulls config info out of a JSON file instead, and parses both HTTP and FILE urls to source the JSON file.) But its effectively abandon-ware (hey, at least it's not a commercial tool.) Maybe I should write a similar package in Janet since that's what I'm doing for fun these days.
Hmm, isn't it better for such core tech to be commercial though? Non-comercial tools tend to be abandanoed pretty frequently. As long as there is a generous free tier, I don't think it's an issue at all
Core tools like Linux, Apache and Node? (to name a few.)
But I think you're talking more like tools that are deployed somewhere (thinking of HashiiCorp Vault, GitHub or AWS.) I guess if you have to run servers to make it add value, then an argument could be made you need a business to collect cash to run the servers.
VSCode is another example. It started off as VizDevStudio's free younger sibling, but had grown into quite the solution of its own.
So yeah... your assertion isn't crazy.
But the reason sn-props was abandoned is it was never advertised outside our small little group. I don't think it adds enough value to warrant putting a company around it, but maybe there's more value buried in there somewhere based on it's interface. Like it could be the interface a kubernetes or lambda like tool uses to communicate config info to apps it automatically starts up in request to scaling events.
Or if you wanted to see it survive, you could popularize it among node users and get a community of people updating it after the original company runs out of money.
I'm sure non-commercial tools getting abandoned is your experience, but I've been using emacs for about 40 years and non-commercial versions of BSD and Linux for 30. I think I started using gcc in the mid-80s.
But the versions of Windows and MacOS I liked have long been EoL'd. I scour ebay to find parts for my Canon Cat. And multiple generations of JTAG probes from otherwise decent companies have gone under the hill.
My experience is when a commercial product's market gets too small, it's abandoned just as readily as an open source project.
> Security. First of all, let's just consider the fact that with .env files you are storing completely unencrypted secrets locally on your machine...
In general, right after people say this, they propose encrypting the secrets somehow but then storing the decryption key completely unencrypted locally right next to them, or something that's equivalent to doing that. Is this an exception?
10 comments
[ 3.4 ms ] story [ 34.4 ms ] threadEnvironment variables/files are certainly not perfect, but this is a very one-sided take on them.
What do you think are the positive benefits of .env files compared to what the author is saying?
Generally speaking the only thing I'm holding in my .env file is the Django secret key, and the debug flag, so, pretty limited use case, but works well I think. I manually create the .env file when setting up my site, so none of it goes into any repos.
Being able to roatate a secret in devenv & have things keep working is early intermediate maturity model, but I'd wager most orgs have nothing.
This isn't a dotenv problem, isn't a security problem. It's that no one has soaked time or your department stoggily refuses to try out the really good Ansible or whatnot env to set your various microservices up for local dev.
https://www.npmjs.com/package/sn-props
But I think you're talking more like tools that are deployed somewhere (thinking of HashiiCorp Vault, GitHub or AWS.) I guess if you have to run servers to make it add value, then an argument could be made you need a business to collect cash to run the servers.
VSCode is another example. It started off as VizDevStudio's free younger sibling, but had grown into quite the solution of its own.
So yeah... your assertion isn't crazy.
But the reason sn-props was abandoned is it was never advertised outside our small little group. I don't think it adds enough value to warrant putting a company around it, but maybe there's more value buried in there somewhere based on it's interface. Like it could be the interface a kubernetes or lambda like tool uses to communicate config info to apps it automatically starts up in request to scaling events.
Or if you wanted to see it survive, you could popularize it among node users and get a community of people updating it after the original company runs out of money.
I'm sure non-commercial tools getting abandoned is your experience, but I've been using emacs for about 40 years and non-commercial versions of BSD and Linux for 30. I think I started using gcc in the mid-80s.
But the versions of Windows and MacOS I liked have long been EoL'd. I scour ebay to find parts for my Canon Cat. And multiple generations of JTAG probes from otherwise decent companies have gone under the hill.
My experience is when a commercial product's market gets too small, it's abandoned just as readily as an open source project.
In general, right after people say this, they propose encrypting the secrets somehow but then storing the decryption key completely unencrypted locally right next to them, or something that's equivalent to doing that. Is this an exception?