.envrc: init #4

Closed

oysteikt wants to merge 0 commits from add-envrc into hovudgren

oysteikt commented

2026-02-09 04:12:37 +01:00

Owner

Adds support for activating the devshell with direnv

Adds support for activating the devshell with [direnv](https://direnv.net/)

oysteikt added 1 commit 2026-02-09 04:12:38 +01:00

.envrc: init 13a6f2b56d

oysteikt requested review from frero 2026-02-09 04:12:38 +01:00

frero commented

2026-02-09 11:09:44 +01:00

Owner

i usually gitignore envrc locally. doesnt it make an assumption about the workflow of contributors? that's been my heuristic for whether i should ignore something or not

though now that i think about it, i have seen many .envrc's in the wild. i guess they can do more than just activating a devshell, so it might be valid to add it

i usually gitignore envrc locally. doesnt it make an assumption about the workflow of contributors? that's been my heuristic for whether i should ignore something or not though now that i think about it, i have seen many .envrc's in the wild. i guess they can do more than just activating a devshell, so it might be valid to add it

oysteikt commented

2026-02-12 05:14:04 +01:00

Author

Owner

doesnt it make an assumption about the workflow of contributors?

To some degree yes, if the contributor is into the habit of using direnv with their own local shells. But I reckon most people either just don't use direnv, don't allow direnv for the current directory or they use the provided shell.

AFAIK, the clashing usecase would be if someone wanted to use envrc with their own devshell instead, and found it annoying that the envrc already exists and would accidentally be git staged all the time after you edit it.

[...] i have seen many .envrc's in the wild. I guess they can do more than just activating a devshell, so it might be valid to add it

I assume you mean outside of this gitea instance, because it is very likely overrepresented here.

From my own experience, the other big usecase (and maybe the initially intended usecase) are devs (typically javascript devs) who use envrc to dynamically load environment variables with API tokens and credentials and possibly other configuration.

It's totally fair if you'd like to leave it out, and keep the repo more clean.

> doesnt it make an assumption about the workflow of contributors? To some degree yes, if the contributor is into the habit of using direnv with their own local shells. But I reckon most people either just don't use direnv, don't allow direnv for the current directory or they use the provided shell. AFAIK, the clashing usecase would be if someone wanted to use envrc with their own devshell instead, and found it annoying that the envrc already exists and would accidentally be git staged all the time after you edit it. > [...] i have seen many .envrc's in the wild. I guess they can do more than just activating a devshell, so it might be valid to add it I assume you mean outside of this gitea instance, because it is very likely overrepresented here. From my own experience, the other big usecase (and maybe the initially intended usecase) are devs (typically javascript devs) who use envrc to dynamically load environment variables with API tokens and credentials and possibly other configuration. It's totally fair if you'd like to leave it out, and keep the repo more clean.

frero added 1 commit 2026-02-12 09:50:09 +01:00