Also mise: https://mise.jdx.dev/environments/
Where .env Went Wrong
31–40 of 77 posts
Re: Where .env Went Wrong
#32Hm, I haven't seen these issues personally. We only have one `.env` file and it's just for local secrets. Configuration emphatically does not go in `.env` and ideally is in docker compose and defined in code (we use Pydantic Settings).
https://x.com/0xPrajwal_/status/2084163731534311627
https://x.com/nilbuild/status/2084339074639200488
The issue is that agents need structure and context.
Re: Where .env Went Wrong
#33Re: Where .env Went Wrong
#34It may be time for Hackernews to integrate a Pangram detector into the UI, similar to what substack is doing :)
Re: Where .env Went Wrong
#35Claude, find a key underpinning of most development workflows, then make a product to disrupt (and eventually SaaSify/enshitify) it. Finally, write a convincing ad disguised blog post, and purchase a fancy domain. Here's my credit card.
Re: Where .env Went Wrong
#3692% of this text is detected as AI. It may be time for Hackernews to integrate a Pangram detector into the UI, similar to what substack is doing :)
Re: Where .env Went Wrong
#37Re: Where .env Went Wrong
#3892% of this text is detected as AI. It may be time for Hackernews to integrate a Pangram detector into the UI, similar to what substack is doing :)
I’m not saying whether I think you’re right or wrong, but AI text detectors don’t work and never will.
Re: Where .env Went Wrong
#39> Environment variables only deliver values
Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default.
> A string is not a schema
Yes, input validation is an application concern. The application should know what these values represent / how to parse them and error if they're invalid.
I could go on, but the article is all about trying to use a hammer as a screwdriver and complaining that the hammer doesnt work.
Re: Where .env Went Wrong
#40This article reads like more of an ad than anything else. > Environment variables only deliver values Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default. > A string is not a schema Yes, input validation is an application concern. The application should know what these values represent /…
This seems like a misunderstanding: The `.env` file should be `source`d into the current shell (environment). The application reads values using whatever mechanism it uses to read these values from the environment. Nothing should be “injected” into the application, i.e. the application should not read `.env` directly.
(Not sure if you were just being loose with your terminology, trying to clarify.)