7 ms·

The number one power move I have is Nix integration. The availability of tooling, secrets, environment and the ability for the agent to modify its own environme

by sshine 4mo ago

The number one power move I have is Nix integration. The availability of tooling, secrets, environment and the ability for the agent to modify its own environment is... well, I don't know how people live without it. I guess you guys still install things using commands and hope everything you need is present on the next machine? Developer machine, CI environment, deployment environment: They're all derived from a single source, and compiling and running always works on every machine. In Claude I use /branch and /rename a lot (context checkpoints, fork, go back) I use sandboxing almost exclusively: https://github.com/nix-tools/bubblebox https://github.com/nix-tools/bubblebox -- it's a generalisation of Numtide's claudebox with a few fixes and some feature additions (more coming). This is best compared to always running your Claude in Docker containers, except there's no Docker runtime. Works fine in WSL and nix-darwin, too.

oulipo2 4mo ago
For those who don't want the complexity of Nix, Mise is a good compromise
- arcanemachiner 4mo ago
  For those who don't know: Mise is a version manager (among other things), and is said to be an improvement over its predecessor, asdf: https://mise.en.dev https://mise.en.dev https://asdf-vm.com https://asdf-vm.com
- _kblcuk_ 4mo ago
  +100. I also dig fnox (encrypted-secrets-in-git) and hk (pre-hooks manager that is actually fast and stays out of the way) by the same author, pretty much default for any project I start nowadays. Though I also use nix to manage my machines :-D
  - sshine 4mo ago
    Awesome, both fnox and hk look very well-made. How does fnox compare to sops? How does hk compare to lefthook? And does hk and fnox have a similar Nix integration as lefthook-nix and sops-nix? I'm still hoping I don't need to make a better lefthook. I kind of like sops-nix, not sure what's missing, really. Maybe fnox is similarly wholesome for non-Nix users. I see that hk has a flake, so that's a good sign. https://github.com/sudosubin/lefthook.nix https://github.com/sudosubin/lefthook.nix https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/ https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/
  - lvncelot 4mo ago
    Ohh fnox looks really cool, with encryption being one possible provider but something like Vault being another. Thanks for the recommendation.
professor_v 4mo ago
I just use docker and I don't feel I'm missing anything?
- sshine 4mo ago
  Docker's ability to mount host directories in the container is really nice. Maybe you have some premade tooling that helps provide persistency between container invocations. But by default, closing your agent container and opening it again just wipes everything you didn't host-mount. What I'm advocating is really just the same functionality without the Docker runtime, because Linux has namespaces. Feels more like you're on your host system with exactly the minor variations you specify. Making Docker feel like your host system is possible, but I just never felt at home.
  - voqv 4mo ago
    yeah, you can use rocker --home --user -- $CI_IMAGE
- fer 4mo ago
  nix develop ensures your dev env is the same as your build/test/prod env. At least with Python everything is a flurry of requirements.txt, Python versions, poetry, pyproject.toml, perhaps automated with direnvs, a hefty Dockerfile/docker-compose, and perhaps conda (ugh) along the way; lots of moving parts. I have a project that's mostly Rust sprinkled with C++ libs and Python helpers and it's easier to manage than the average virtualenv. Everything builds with nix build, everything runs with nix run, profiler/debugger works, IDE detects everything on any of my computers, builds and links with CUDA on x86, aarch64, NixOS, MacOS, Ubuntu or Amazon Linux. nix build can even build a Docker image for the odd need of Docker, and I haven't tried but I'm convinced that if I import the flake on my nix-config it will be built into the SD card for my Raspberry Pi just fine. It's even replaced Ansible for me, colmena all the way.
  - chrisweekly 4mo ago
    Pythonistas have mostly moved to uv, which solves much of the "flurry" you describe. Tools like Mise add more of the benefits ascribed to nix. And smolmachines' smolvms can provide better isolation than Docker. Just saying, TIMTOWTDI. Not hating on nix, just pointing out it's not the only game in town.
aqme28 4mo ago
I just gave mine its own VPS. Maybe more expensive than Nix but it was very easy
- sshine 4mo ago
  I also prefer giving it a VPS over a Docker container. On my own machine I just give it a Linux User Namespace, i.e. soft virtualisation via "bubblewrap." What Docker Compose and Linux User Namespaces provide that a VPS doesn't: You can easily mount extra directories from your developer host machine in read or read+write mode. With the VPS you (most likely) need it to clone all of your resources separately, which requires SSH keys, and now you're slowly building towards an independent agentic environment, which is definitely very nice, but time-consuming, compared to piggybacking on your developer environment. Definitely the direction I'm going.
uberduper 4mo ago
I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point. Codex is way better at nix than I am.
- sshine 4mo ago
  If you generate Dockerfiles using Nix code, how do you build and run those images? Docker? I use NixOS on my self-hosted CI runners, and I generate the OCI image using Nix via pkgs.dockerTools: https://git.shine.town/infra/runners/src/branch/main/nix/nixos-runner.nix#L76-L109 https://git.shine.town/infra/runners/src/branch/main/nix/nix... It has nothing to do with Docker as such, it's just named that. https://nix.dev/tutorials/nixos/building-and-running-docker-images.html https://nix.dev/tutorials/nixos/building-and-running-docker-...
  - uberduper 4mo ago
    Nix isn't involved in my container images. I just take the dependencies and env vars from the flake and generate a dockerfile. Guess I need to try out dockerTools. That looks really convenient. Thanks!
toastal 4mo ago
Yikes. That Nix code is a mess without meaningful organization & only usable via experimental flakes.
- sshine 4mo ago
  There are two kinds of organization happening here that you might not see: 1. All .nix files (besides flake.nix) are flake-parts modules: https://flake.parts/ https://flake.parts/ 2. It's not only usable with experimental flakes. Works fine with unflake or trix. The experimental part of flakes is enabling flake support in the `nix` CLI. Flakes are also a design pattern in pure Nix syntax that can be evaluated fine without the experimental flag. If you're curious about this meaningful organization, it's pretty well-documented: https://denful.dev/ https://denful.dev/ As for the experimental nature of flakes, it's more of a social experiment by now: https://simonshine.dk/articles/if-flakes-are-experimental-whats-the-experiment/ https://simonshine.dk/articles/if-flakes-are-experimental-wh...
  - neobrain 4mo ago
    (for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)
    - sshine 4mo ago
      Hahaha, I didn't see. Hi toastal, I appreciate your work.
      - toastal 4mo ago
        ຂອບໃຈເດີ້
  - toastal 4mo ago
    Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).

by sshine 4mo ago

oulipo2 4mo ago

For those who don't want the complexity of Nix, Mise is a good compromise

arcanemachiner 4mo ago
For those who don't know: Mise is a version manager (among other things), and is said to be an improvement over its predecessor, asdf: https://mise.en.dev https://mise.en.dev https://asdf-vm.com https://asdf-vm.com
_kblcuk_ 4mo ago
+100. I also dig fnox (encrypted-secrets-in-git) and hk (pre-hooks manager that is actually fast and stays out of the way) by the same author, pretty much default for any project I start nowadays. Though I also use nix to manage my machines :-D
- sshine 4mo ago
  Awesome, both fnox and hk look very well-made. How does fnox compare to sops? How does hk compare to lefthook? And does hk and fnox have a similar Nix integration as lefthook-nix and sops-nix? I'm still hoping I don't need to make a better lefthook. I kind of like sops-nix, not sure what's missing, really. Maybe fnox is similarly wholesome for non-Nix users. I see that hk has a flake, so that's a good sign. https://github.com/sudosubin/lefthook.nix https://github.com/sudosubin/lefthook.nix https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/ https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/
- lvncelot 4mo ago
  Ohh fnox looks really cool, with encryption being one possible provider but something like Vault being another. Thanks for the recommendation.

professor_v 4mo ago

I just use docker and I don't feel I'm missing anything?

sshine 4mo ago
Docker's ability to mount host directories in the container is really nice. Maybe you have some premade tooling that helps provide persistency between container invocations. But by default, closing your agent container and opening it again just wipes everything you didn't host-mount. What I'm advocating is really just the same functionality without the Docker runtime, because Linux has namespaces. Feels more like you're on your host system with exactly the minor variations you specify. Making Docker feel like your host system is possible, but I just never felt at home.
- voqv 4mo ago
  yeah, you can use rocker --home --user -- $CI_IMAGE
fer 4mo ago
nix develop ensures your dev env is the same as your build/test/prod env. At least with Python everything is a flurry of requirements.txt, Python versions, poetry, pyproject.toml, perhaps automated with direnvs, a hefty Dockerfile/docker-compose, and perhaps conda (ugh) along the way; lots of moving parts. I have a project that's mostly Rust sprinkled with C++ libs and Python helpers and it's easier to manage than the average virtualenv. Everything builds with nix build, everything runs with nix run, profiler/debugger works, IDE detects everything on any of my computers, builds and links with CUDA on x86, aarch64, NixOS, MacOS, Ubuntu or Amazon Linux. nix build can even build a Docker image for the odd need of Docker, and I haven't tried but I'm convinced that if I import the flake on my nix-config it will be built into the SD card for my Raspberry Pi just fine. It's even replaced Ansible for me, colmena all the way.
- chrisweekly 4mo ago
  Pythonistas have mostly moved to uv, which solves much of the "flurry" you describe. Tools like Mise add more of the benefits ascribed to nix. And smolmachines' smolvms can provide better isolation than Docker. Just saying, TIMTOWTDI. Not hating on nix, just pointing out it's not the only game in town.

aqme28 4mo ago

I just gave mine its own VPS. Maybe more expensive than Nix but it was very easy

sshine 4mo ago
I also prefer giving it a VPS over a Docker container. On my own machine I just give it a Linux User Namespace, i.e. soft virtualisation via "bubblewrap." What Docker Compose and Linux User Namespaces provide that a VPS doesn't: You can easily mount extra directories from your developer host machine in read or read+write mode. With the VPS you (most likely) need it to clone all of your resources separately, which requires SSH keys, and now you're slowly building towards an independent agentic environment, which is definitely very nice, but time-consuming, compared to piggybacking on your developer environment. Definitely the direction I'm going.

uberduper 4mo ago

I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point. Codex is way better at nix than I am.

sshine 4mo ago
If you generate Dockerfiles using Nix code, how do you build and run those images? Docker? I use NixOS on my self-hosted CI runners, and I generate the OCI image using Nix via pkgs.dockerTools: https://git.shine.town/infra/runners/src/branch/main/nix/nixos-runner.nix#L76-L109 https://git.shine.town/infra/runners/src/branch/main/nix/nix... It has nothing to do with Docker as such, it's just named that. https://nix.dev/tutorials/nixos/building-and-running-docker-images.html https://nix.dev/tutorials/nixos/building-and-running-docker-...
- uberduper 4mo ago
  Nix isn't involved in my container images. I just take the dependencies and env vars from the flake and generate a dockerfile. Guess I need to try out dockerTools. That looks really convenient. Thanks!

toastal 4mo ago

Yikes. That Nix code is a mess without meaningful organization & only usable via experimental flakes.

sshine 4mo ago
There are two kinds of organization happening here that you might not see: 1. All .nix files (besides flake.nix) are flake-parts modules: https://flake.parts/ https://flake.parts/ 2. It's not only usable with experimental flakes. Works fine with unflake or trix. The experimental part of flakes is enabling flake support in the `nix` CLI. Flakes are also a design pattern in pure Nix syntax that can be evaluated fine without the experimental flag. If you're curious about this meaningful organization, it's pretty well-documented: https://denful.dev/ https://denful.dev/ As for the experimental nature of flakes, it's more of a social experiment by now: https://simonshine.dk/articles/if-flakes-are-experimental-whats-the-experiment/ https://simonshine.dk/articles/if-flakes-are-experimental-wh...
- neobrain 4mo ago
  (for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)
  - sshine 4mo ago
    Hahaha, I didn't see. Hi toastal, I appreciate your work.
    - toastal 4mo ago
      ຂອບໃຈເດີ້
- toastal 4mo ago
  Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).