I am quite intrigued. With the sorry state of security, I am doing everything in VMs and have been trying to settle on the best way to setup a new machine. The process is so clunky that I end up defaulting to bigger instances than I should (more pets than cattle).

Being able to centralize this config is far more attractive than having a separate Ansible or pyinfra process.

Just started moving things to mise and didn’t see this before, thanks.

Hopefully can use this alone instead of needing to combine w/ chezmoi / nix to get everything shell and pkg manager agnostic, consistent, and DRY (bash/zsh/fish + macports/pkgsrc/brew).

Are there plans to support MacPorts as a packaging system? I only use Homebrew for casks, because I find it unreliable for core development tools.

Ha, I came here to share this! :)

Thanks so much for your work on mise! I used to be a heavy asdf user but nowadays I'm an even heavier mise user!

Random question while you're here: mise is undergoing pretty heavy development these days and I recently noticed that 1) my coworkers and I are not always on the same version, so some features/bug fixes are not available to everyone, and 2) package registries often don't have the latest mise version.

So I think we need a meta tool manager here to manage the tool manager version. :) Seriously, though, have you considered having mise manage its own version? I think that'd be pretty neat!

Thinking aloud, I guess one way to do this might be to distribute through package registries only a lightweight bootstrap application, which 1) reads the pinned mise version from mise.toml and downloads it as necessary, and 2) sets up a basic shell hook that the active mise version can then hook into(?) I know, this probably sounds a lot easier than it actually is.

If you like home manager but also like to understand how your "home"/user programs are configured, take a look at hjem!

People shy from Nix because of supposed complexity but it really is the only real solution to this sort of problem. It's not really that much more difficult to learn, and in fact if you are willing, AI works really well generating nix config.

I didn't even know that managing dotfiles was a "problem space".

I'm pretty committed to the `nix` ecosystem (I rewrote `nix` from scratch to unbreak it: https://gist.github.com/b7r6/90107d8e8ebe81fb0577b9c033b6ab0..., so, pretty committed), but I can't endorse it in it's current form after learning how the sausage is made and enough math to know why it's not just buggy but conceptually unsalvagable with the current `nixpkgs` and the current purity dogma.

And `home-manager` is maybe the most glaring instance of a tool that is demonstrably ill-posed where the "you're holding it wrong" from the community is a the community problem, not anyone holding anything wrong. From the Zed editor configuration stanza in `home-manager`: https://github.com/nix-community/home-manager/blob/a78606767.... That's not a Zed problem, that's a Nix problem. No one is holding it wrong, XDG config paths get mutated.

Another example and this is the one that really shows the shape of the thing: https://github.com/nixified-ai/flake/blob/bbd3a04fa1ae294096....

There is absolutely nothing "impure" about taking content-addressed bytes from a CAS (Xet in this instance) and surfacing them as a derivation. The "impurity" is called a "coeffect" and the action over the coeffect is called "grade discharge". This is thoroughly studied and works properly, it can cope with all of these cases and it's creates scope for dramatically more reproducible systems that are much easier to reason about (they are possible to reason about). Also, if you can't download shit from HuggingFace in 2026 without a weird hack where the name of the field is a scolding? That's gonna be putting downward pressure on adoption.

And most of the high-friction shit in Nix is like this, ignorance hardened into dogma hardened into theology. To wit:

- FHS vs. zany one-of-a-kind filesystems are nothing to do with purity or hermeticity or reproducibility, it's pure theology and the constant breakage with all the `patchFail` jank is at this point a jobs program, it's totally unnecessary. Namespaces/unshare, we have all the stuff to do this properly (`patchelf` and `unshare --bind-mount` are mathematically dual but only one blows content addressing).

- `drv` hash addressing is a reproducibility war crime. Floating CA is fine it's just broken upstream and in Determinate, it's not a valid ideological debate, it's bugs.

- there is absolutely no reason why the builder where a binary is produced needs to have the same filesystem layout or find libraries in the same place as the resulting artifact runs in any more than an adult needs to live in the same house they grew up in. `patchelf` works.

- having `libcuda.so.1` and friends at `/run/opengl-driver/lib` is dark comedy and source builds of `NCCL` when NVIDIA-certified binaries are in a wheel (zip file) on PyPI is the sequel. this is straight up bad for the planet and we should feel bad we haven't fixed it.

I could go on, but the main point for this thread is to the people who are on the fence about Nix: you're not holding it wrong the `nixpkgs` maintainers are holding it wrong, and more and more of us are getting serious about fixing it. Don't give up on declarative and reproducible systems that you can reason about because Nix is stuck in a weird place as software and as a community. There are reformers on the case.

I ran NixOS for a while, before I switched to Apple Silicon, so I consider myself fairly well-versed-enough (although nowhere near an expert) in Nix and the Nix ecosystem. My last four jobs have all issued me MacBook Pros; the last three with Apple Silicon.

Ultimately, my workplace setup is what has the most gravity. And the most I can get most workplaces to standardize on is Homebrew for package management of off-the-shelf software. Nix is so far outside of the wheelhouse for most engineers that I can't even propose it. It would be too much of a distraction for too many people for too long that it's just not seen as worth it and it's not worth spending the political capital on the attempt. Employers would literally prefer to run scripts from a whitewashing, barely-auditable Jenkins instance with parameterized jobs than to attempt to figure out how to distribute portable scripts and get everyone's permissions working.

So I need to pick software that will cooperate with other tools in an unstable fashion, rather than software that attempts to fully and exclusively control the environment to provide guarantees. Chezmoi fits. Nix and home-manager do not.

I've bounced off Nix every time I tried it, before I even started trying something like Home Manager.

I've been using (and contributing to) chezmoi for ~6 years now. Given that it has first-class integration with secrets managers, I suspect that it does things that Home Manager can't.

Or nix without home manager, and ideally without flakes as well. Two solutions looking for problems, IME.

don't want to be that guy, but have you tried nix?

I've been happy with yadm for few years now. I had tried chezmoi, but preferred yadm. I don't remember my exact reasons though...

[delayed]

I used stow for a long time, then tried Ansible, but eventually settled into good old Make.

`make dotfiles` just creates a bunch of symlinks, takes 5 minutes, all good and happy. Everything is modular, declarative, simple. Never looked back.

Same here. I would say chezmoi has almost a bit too many features. If one is into yak shaving there is a lot to explore. It's only a negative for me because I forget half of them everytime I read the docs. But I can hardly blame it for that, it's great!

I nearly jumped from GNU Stow, but settled when I find the —-no-folding flag

Interesting. I go about this differently. I have one master setting and from there ruby just autogenerates anything I'd ever need on other computers. If ruby is unavailable then I just copy the generated files. But I only edit the master setting to enable what I need.

> This process has served me well for at least 15 years now and is supported by a small handful of shell scripts to automate this process

I feel in a similar way but not with shell scripts. Ruby autogenerates them if I need them too. Ruby is my ultimate glue to hold together everything.

You might like xdg-ninja‡ then, it tells you what program put which item in your $HOME and how to move it to ~/.config or $XDG_CONFIG_HOME.

‡: https://github.com/b3nj5m1n/xdg-ninja

Found the Kubernetes guy

;)