domenkozar

Install it outdoors or in a detached garage, away from anything flammable. Never in a bedroom, hallway, or escape route.

There are newer batteries tech that can't inflame.

He has fixed the oldest and most upvoted issue on devenv: https://github.com/cachix/devenv/issues/16

Basic example in devenv:

  { multiverse, ... }: {
    packages = [
      multiverse.cmake."3.16.5"
      multiverse.bun."0.7.0"
    ];
  }

https://x.com/0xPrajwal_/status/2084163731534311627

https://x.com/nilbuild/status/2084339074639200488

The issue is that agents need structure and context.

The difference is that we're providing an interface for applications to build with, with 8 SDKs available so you can have first-class support for secrets whatever you're bulding. I do hope fnox copies that too!

- Secrets don't belong in config https://secretspec.dev/blog/secrets-dont-belong-in-config/

- You want to have flexibility of choosing between any secrets provider: https://secretspec.dev/blog/but-i-use-sops/

- haskell exceptions and laziness are devastating for production

- too small ecosystem, had to write 10+ SDKs (now with AI that's less of an issue)

- haskell ecosystem is too fragmented due to prima donna prevalence

We need more general purpose Elm languages in the space.

You can do things like creating ad-hoc environments:

$ devenv -O languages.rust.enable:true shell

Once you teach your coding agent to use it, it will just use it to get packages if needs any: https://devenv.sh/integrations/claude-code/#global-configura...

https://github.com/cachix/cloud.devenv.sh

Syntax of toml is almost identical, the CLI as well.

It even has the same vocabulary.

I didn't dig deeper though, but I'd be surprised not to find more :)

Think of devenv as systemd of developer environments.

It results into speed up in a way that if your application doesn't change, you'll just get the binary package.

That's why the two interfaces are exposed: one for development feedback cycle and one for distribution.

I'm not sure exactly what parts of the comment are about secrets rather than how infrastructure should be done, but I see that secrets and configuration have very different lifetimes so they should be provisioned separately. The config can for example be in the git if it's free of secrets.

Secrets are provisioned at runtime, while config is build time.

`secretspec.toml` is in the version control and it tells you all about what's going to happen at runtime.

By having a secrets specification we can start working towards a future that will consolidate these providers and allow teams to centralize it if needed, by having simple means of migrating from a mess into a central system.

We hope that one day github actions would integrate secretspec more tightly, leaving aside using environment variables as a transport.

That's going to be a long journey, one worth striving for.