I recently used clause code to help me learn nix + home-manager!
For anyone considering it - it’s been fun, genuinely useful in my day to day, and I can’t recommend it enough - I now have a source controlled tool kit that I can take with me anywhere I go
ika•Apr 3, 2026
I agree. I started with Nix flakes in my project and fell in love with them. Then I started using Home Manager, and now I feel complete. I even played with nix-darwin and NixOS. It's an amazing piece of software.
dewey•Apr 3, 2026
I’ve gotten used to it and with LLM it’s easier to set up the config without learning all the obscure syntax but on macOS it’s still a very un-native feeling compared to home brew. Having to sudo all the time feels weird for just updating user space apps and configs.
theowaway213456•Apr 3, 2026
Five years ago, I would've loved this. I love the simplicity and power of good old Make. And I obsess over my workstation's configuration. I used to have a massive bash script I would use to reprovision my workstation after every clean upgrade of Ubuntu.
But these days, I just tell codex to install things for me. I basically use it as a universal package manager. It's more reliable honestly than trying to keep up to date with "what's the current recommended way to install this package?"
I also have it keep a list of packages I have installed, which is synced to GitHub every time the list changes.
If you haven’t tried it, I highly recommend Mise. It manages everything at the user level so it’s not as “all encompassing” as Nix and is readily compatible with immutable distros.
Your solution is akin to putting your dotfiles in the code repo, which is going to cause issues with languages with poor version compatibility (such as node and python) when switching between old projects.
Also, bold of you to assume developers know make and bash just because they’re using Linux!
igor47•Apr 3, 2026
I cannot endorse mise more highly. I commit it to my repos to make sure every engineer has the same environment. I use it in CI for consistency there as well. I keep all commands that would normally be documented in a readme as mise tasks. I use mise to load the environment, independent of language specific tools like dotenv. I use a gitignored mise.local to put real creds into the environment for testing.
ManuelKiessling•Apr 3, 2026
These days, all dev tooling of my projects lives behind mise tasks, and the runtime for my projects is Docker.
This means that getting a project in shape for development on a new system looks like this:
- clone project
- `mise run setup`
I have zero dev tools on my host, projects are 100% self-contained.
I use mise, but its conclusion that everybody needs to write an aqua plugin now is annoying. They need to make plugin-making a lot easier.
saint_yossarian•Apr 3, 2026
What conclusion do you mean? Aqua is just one of the many backends it supports.
For example there's also the GitHub backend which lets you install binaries from releases, no plugin needed at all.
zelphirkalt•Apr 3, 2026
Question about Mise: Does it manage checksums or a lock file per environment somewhere? I scrolled through the getting started page and didn't see anything at first glance.
ricardobeat•Apr 3, 2026
Releases are signed, but lockfiles are not commonly used for this purpose. For your home env you'll usually want the latest version of every tool.
When installing tools, or via mise.toml, you can define version ranges with the precision you'd like - "3" / "3.1" / "3.1.2".
figmert•Apr 3, 2026
Mise supports lock files but also validates checksums when possible.
The main difference is I initially only needed a mechanism to check if my "Manually-Installed or Source -Compiled" (MISC) packages have updates, but now it also supports install/upgrading too.
In other words, things I am forced to do by hand outside of a package manager, I now only do by hand once, save it as an 'install' script, and then incorporate it into this system for future use and to check for updates. Pretty happy with it.
tmarice•Apr 3, 2026
I’ve been using devenv.sh for the last year for this, and never been happier.
0xbadcafebee•Apr 3, 2026
I codify all my AI install/setup/running junk (https://codeberg.org/mutablecc/ai-agent-coding) with Makefiles. You can make DRY Makefiles real easy, reuse them, override settings, without the fancy stuff in the author's post. The more you build up a reusable Makefile, the easier everything gets. But at the same time: don't be afraid to write a one-off, three-line, do-almost-nothing Makefile. If it's so simple it seems stupid, it's probably just right.
stevekemp•Apr 3, 2026
I like the way that golang supports the use of tools in the go.mod file.
Something like:
go get -tool github.com/golangci/golangci-lint/cmd/golangci-lint@v1.64.4
And youre ready to go, everything confined to the venv within the directory
landdate•Apr 3, 2026
Alternatively, you can use the guix package manager. See here: https://guix.gnu.org/
Configuration is in scheme (guile) so that may be a turn off though.
rekado•Apr 3, 2026
I use a Guix manifest for every project, which describes what dev tools and dependencies I want. When I enter a directory the shell automatically evaluates the manifest and all my tools are ready.
With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.
loveparade•Apr 3, 2026
Or just use nix with home manager. Battle tested, lots of built-in functionality, works perfectly. Author claims the learning curve for it is weeks, but I had my setup up and running in a 1-2 hours at most and have been super happy with it.
IshKebab•Apr 3, 2026
This must be a different "just" from the just I'm used to!
Weeks sounds way more accurate than 1-2 hours.
loveparade•Apr 3, 2026
Now with LLMs it's even easier. Writing nix code is hard, but reading it is straightforward because it's declarative, so you can easily review what an LLM produces. And it's not much code either, a simple home manager setup is maybe 100 lines total.
Ah yeah I wouldn't count that as being a small learning curve because you haven't actually learnt anything.
Valid approach though I guess.
axegon_•Apr 3, 2026
I used to do that but there are a few catches. As much as I brush off people who use any OS other than Linux, there is a time when you will have to do something on another operating system. A lesson I learned the hard way: Make on Windows sucks royally. While I agree with the general idea and I also tend to be conservative about new technologies (even more so with all the slop-coding lately), just[1] is now a very mature and well thought out alternative.
There's already a bunch of comments about Nix, so I don't want to repeat them, but really Nix is less complex than a handcrafted series of Makefiles, and significantly more versatile.
With home-manager I have the same packages, same versions, same configuration, across macOS, NixOS, Amazon Linux, Debian/Ubuntu... That made me completely abandon ansible to manage my homelab/vms.
Also adding flake.nix+direnv on a per project basis is just magical; I don't want to think how much time I would have wasted otherwise battling library versioning, linking failures, etc.
duskdozer•Apr 3, 2026
I've ended up using a pseudo-make bash script with a helper that runs functions only once, mainly because I find adding new stuff to a makefile more annoying, and less intuitive and readable. Haven't come up with something easier so far
redoh•Apr 3, 2026
The fzf integration is a really nice touch here. Half the battle with dev tool management isn't installing things, it's remembering what you installed and how six months later. I know everyone's going to recommend Nix (and they already have), but there's something to be said for a solution where the entire logic fits in your head on first read. I've had a similar Makefile-based setup for years and the biggest win is onboarding new team members who can just read the targets and immediately know what's available.
16 Comments
But these days, I just tell codex to install things for me. I basically use it as a universal package manager. It's more reliable honestly than trying to keep up to date with "what's the current recommended way to install this package?"
I also have it keep a list of packages I have installed, which is synced to GitHub every time the list changes.
https://mise.jdx.dev/
Your solution is akin to putting your dotfiles in the code repo, which is going to cause issues with languages with poor version compatibility (such as node and python) when switching between old projects.
Also, bold of you to assume developers know make and bash just because they’re using Linux!
This means that getting a project in shape for development on a new system looks like this:
- clone project
- `mise run setup`
I have zero dev tools on my host, projects are 100% self-contained.
Pure bliss.
See https://github.com/dx-tooling/sitebuilder-webapp for an example.
For example there's also the GitHub backend which lets you install binaries from releases, no plugin needed at all.
When installing tools, or via mise.toml, you can define version ranges with the precision you'd like - "3" / "3.1" / "3.1.2".
The main difference is I initially only needed a mechanism to check if my "Manually-Installed or Source -Compiled" (MISC) packages have updates, but now it also supports install/upgrading too.
In other words, things I am forced to do by hand outside of a package manager, I now only do by hand once, save it as an 'install' script, and then incorporate it into this system for future use and to check for updates. Pretty happy with it.
Something like:
And then you can list tools : ANd run them:pixi init && pixi add wget
And youre ready to go, everything confined to the venv within the directory
Configuration is in scheme (guile) so that may be a turn off though.
With tooling for deployment I prefer to heed an adaptation of Greenspun's Tenth Rule. Neither Guix nor Nix are really all that "complex" from a user's perspective.
Weeks sounds way more accurate than 1-2 hours.
1. Install nix / determinate nix
2. Tell your favorite llm to set up https://github.com/nix-darwin/nix-darwin with home manager if you are on mac, or just home manager if you are on linux
3. Review the code and ask for clarifications
You'll have a set up in 20 minutes.
Valid approach though I guess.
[1] https://github.com/casey/just
With home-manager I have the same packages, same versions, same configuration, across macOS, NixOS, Amazon Linux, Debian/Ubuntu... That made me completely abandon ansible to manage my homelab/vms.
Also adding flake.nix+direnv on a per project basis is just magical; I don't want to think how much time I would have wasted otherwise battling library versioning, linking failures, etc.