.env is self sustaining at this point. The functionality described in the post exists to help move people off of it. It’ll have a better chance of dying when fewer people use it and that starts with making it easy to move away from it.
How exactly changing a default that users rely on is going to make it easy to move away from it?
Instead of migrating to dotenv-ng, these users could be putting effort into migrating away from .env files entirely.
edit: I understand SecretSpec needs to parse .env files exactly like Node.js’s dotenv library, which doesn’t support interpolation, to make it easier for these projects to use SecretSpec.
I’m saying making this a standalone library is bad. Rust projects will pick this up and use it instead of SecretSpec, and users of the unmaintained Rust crate will migrate to it.
Or even simpler: why on earth are you using double quotes for a string if you don't want double-quote behaviour? Anything like this should just be in 'single quotes'... Any developer getting to "its parser changed a secret while reading it" and "By the time the bcrypt bug blocked SecretSpec," from basic shell semantics is frankly astonishing. I mean this on an organisational/team level, not as a personal attack on anyone, but the hubris is incredible to me.
This feels like the exact type of solution a badly prompted and poorly piloted AI tool manically follows to an absurd conclusion if you don't step in and tell it to do it the obvious and correct way instead of re-inventing the wheel.
(I would also argue most of the point of a .env file being what it is that you can source it in a shell?
Does the author here have any sane argument for not using a yaml/json/whatever file and XKCD-927ing it instead? Is this not just introducing a flaw when `source .env` stops behaving like expected?)
Comments
Can’t you just escape the dollar sign?
If you really believe .env was a mistake (it was), just let it die. You are the ones keeping it alive now.
.env is self sustaining at this point. The functionality described in the post exists to help move people off of it. It’ll have a better chance of dying when fewer people use it and that starts with making it easy to move away from it.
How exactly changing a default that users rely on is going to make it easy to move away from it?
Instead of migrating to dotenv-ng, these users could be putting effort into migrating away from .env files entirely.
edit: I understand SecretSpec needs to parse .env files exactly like Node.js’s dotenv library, which doesn’t support interpolation, to make it easier for these projects to use SecretSpec.
I’m saying making this a standalone library is bad. Rust projects will pick this up and use it instead of SecretSpec, and users of the unmaintained Rust crate will migrate to it.
Or even simpler: why on earth are you using double quotes for a string if you don't want double-quote behaviour? Anything like this should just be in 'single quotes'... Any developer getting to "its parser changed a secret while reading it" and "By the time the bcrypt bug blocked SecretSpec," from basic shell semantics is frankly astonishing. I mean this on an organisational/team level, not as a personal attack on anyone, but the hubris is incredible to me.
This feels like the exact type of solution a badly prompted and poorly piloted AI tool manically follows to an absurd conclusion if you don't step in and tell it to do it the obvious and correct way instead of re-inventing the wheel.
(I would also argue most of the point of a .env file being what it is that you can source it in a shell? Does the author here have any sane argument for not using a yaml/json/whatever file and XKCD-927ing it instead? Is this not just introducing a flaw when `source .env` stops behaving like expected?)