[aerzen]

This is the way. We should make it a standard practice for oss projects that one is able to git clone, direnv allow and build the project.

Regardless of the distro or even OS. An easy thing to say, but hard to execute on actual projects with patched versions of cPython and some obscure in-house build tool.

[drowsspa]

I would love for an ARCHITECTURE.md to become standard as well... I've definitely skipped contributing to a lot of projects because I'd have to basically have to reverse engineer the project, configuring a dev environment and add a lot of breakpoints to even begin to understand the structure

[arnorhs]

I wouldn't put an .envrc file in source control. This seems like an anti-pattern.

I think it should be standard practice that you can pull and run a project without configuring environment variables. I agree with that. The defaults should work.

This is not always possible (when you have something that absolutely relies on a third party thing, which you need an environment variable for) - in which case you should be greeted with a helpful error telling you what environment variables you need to set up and why.

[NoThisIsMe]

It is absolutely not an anti pattern to check Direnv's `.envrc` in to source control, and if you don't then you're passing up on much of Direnv's value proposition.

Obviously don't put secrets in there. For secrets and overrides you can use separate a `.env` file which is not checked in, and source it in `.envrc` with `dotenv_if_exists`

[Fire-Dragon-DoL]

The moment you commit an envrc file, you disallow the developer from using direnv for that directory to configure stuff related to their machine. It is an anti pattern, it was never meant to be committed. Put an envrc.example in repo if you want, or an envrc.project in there and tell the dev to load it (load_if_exists in direnv)

[pxc]

You can use direnv in conjunction with sops or your favorite cloud-centric secrets management utility to automate secrets handling without writing any plaintext secrets (or any secrets at all, if you want) to version control.

.envrc is a whole bash script, so it can invoke command line tools that fetch secrets over the network or decrypt them from the disk.

[NoThisIsMe]

Yep that too

[crabbone]

This is an awful idea.

It's very hard to define in general what it means to build a project, what are the expected inputs and outputs. Not every build aims to produce the same artifacts, not using the same inputs etc.

What you want could be based on some typical practice in a particular field with a particular project size or structure, but this doesn't transfer well to other fields.

[b112]

As long as it doesn't interfere with supporting normal, non container builds, sure.

[cqqxo4zV46cp]

What interferes with supporting “normal” builds is the effort required to actually support them. If that was a given, there’d be no justification for us having gotten ourselves in this mess in the first place. The realities of increasingly choose-your-own-adventure nature of Linux have come home to roost, and people are quite rightfully wanting to spend their effort elsewhere.

I say this as someone that was using Gentoo before lxc even existed. So this isn’t code for “I don’t get it”.

[bartekrutkowski]

What about non Linux operating systems? Those exist and Open Source software written for them, developed on them exists.