Live data from Hacker News

Where .env Went Wrong

secretspec.dev

31–40 of 77 posts

Re: Where .env Went Wrong

#31

Also mise: https://mise.jdx.dev/environments/

That's what we are using as well in our small team. `mise` for our non-sensitive values/ environment variables and then `fnox` (from the same author) to encrypt and manage the secrets. `mise` has a plugin for `fnox` that allows to automatically load the secrets in the context when running a mise task/command. This way, our secrets are never exposed, even during local development. Setting this up was effortless. Pretty happy about these tools.

Re: Where .env Went Wrong

#32

Hm, 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/NoeticsTech/status/2071136897985138897

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

#34
92% 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

#35
post #6

Claude, 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.

[deleted]

Re: Where .env Went Wrong

#36
post #34

92% 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

#37
This is why I love direnv (the tool) and just a simple .envrc (not .env). It has none of the problems posited in the OP's article. It assumes nothing, only that direnv manges loading up the .envrc into your shell.

Re: Where .env Went Wrong

#38
post #36
post #34

92% 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.

Doesn't stop charlatans from creating startups promising to make it work :)

Re: Where .env Went Wrong

#39
This 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 / 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

#40

This 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 /…

> 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.

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.)

Post reply on HN