Thoughts on mise's new bootstrap and dotfiles features?

[sassdavid]

Since DotFriedRice already leans on mise for tool installs, I figured this might be worth a look: mise recently grew two features that overlap with parts of what the dotfriedrice script does.

• https://mise.jdx.dev/bootstrap.html
• https://mise.jdx.dev/dotfiles.html

mise bootstrap is a declarative machine setup step (system packages per manager, repos, systemd units / launchd agents, files with owner+mode, macOS defaults, shell activation), and [dotfiles] handles symlinking/copying/templating config files with symlink, symlink-each, copy and template modes, plus status/apply --dry-run.

Very high level, the parts of this repo that map onto it:

_install/default/config_install — the ln -fns lists could become:

[dotfiles]
"~/.config/bat/config" = { mode = "symlink" }
"~/.config/nvim" = { mode = "symlink" }
"~" = { source = ".config/zsh", mode = "symlink-each" }

_install/default/packages/{arch,darwin,debian} — DEFAULT_PACKAGES_PACMAN, DEFAULT_PACKAGES_BREW, DEFAULT_PACKAGES_BREW_CASK etc. have a direct equivalent:

[bootstrap.packages]
"pacman:tmux" = "latest"
"brew:tmux" = "latest"
"brew-cask:ghostty" = "latest"

DEFAULT_SYSTEMD_ENABLED_SERVICES and the sudoers/udev entries look like [bootstrap.linux.systemd.units] / [bootstrap.services] and [bootstrap.files."/etc/..."] with owner/mode. And mise bootstrap dotfiles status --missing is a CI-friendly check for drift.

Things I'm genuinely unsure about, and why I'm asking rather than suggesting:

• The theme switching (dfr-theme-set re-pointing symlinks at runtime) is dynamic, whereas dotfiles apply is a converge-to-desired-state operation, so that probably stays as-is either way.
• DFR's per-item _SKIP / _EXTRAS override pattern and the "warn before overwriting an unmanaged real file" behaviour are nicer than what I've seen from the mise side so far.
• Both features are new, so there's a moving-target risk, and it would add mise as a hard dependency for config linking, not just tools.

Not arguing for a rewrite — mostly curious whether you think any slice of this is worth adopting (even just the [dotfiles] part, or the status check in CI), or whether the bash approach stays the better fit here. Happy to leave it at that if it's not interesting.

[nickjj]

Thanks for the heads up. Personally I think it's more streamlined to keep it as is because the interface to everything is mostly a single shell script + shell based config files. Everything is set up and provisioned the same. It would be more complicated to maintain for both users and myself if only a few things were managed by mise, this is compounded by also needing to keep up with mise's features around this.

Your call outs are valid around what looks to be limited by mise (theming, skipping, etc.). I think the mise bootstrap config will be harder to manage if you want to change it because it would need to be git ignored so each machine can have its own set of packages and other configs, but at the same time you'd probably want a lot of things pre-defined. _SKIP and _EXTRAS are patterns to help avoid needing to manually keep everything in sync during updates.

I've used Ansible for around 12 years, it's a general purpose machine provisioning tool. I almost made DFR with it, but decided against it because it tends to be slow (even over localhost), but it's also a completely separate tool that needs to be learned by the user and also kept compatible with various versions. That's how I landed on shell scripts in the end. It's not perfect but it's fast and general purpose with a pretty clean API for doing the things DFR does.

Do you find anything limited with the current implementation?

I have thought about adding hooks at various stages but always talked myself out of it because I haven't had a real use case for it yet. UDEV_RULES was the one thing where I was like "if hooks existed, this would be easy to customize per machine" but then I thought about the problem more and it made sense to create it as a top line feature with its dedicated config item.

[sassdavid]

That all makes sense, and the gitignore point is a good one, I hadn't thought it through that far. A shared-by-default config with a small per-machine slice is exactly what _EXTRAS / _SKIP gives you, and a single bootstrap file that's either tracked or not doesn't really have an answer for that.

To your question: no, I haven't run into anything limiting. The single-script plus shell-config interface has been fast and predictable, and the fact that everything is provisioned the same way is a real part of why it's easy to follow. Your Ansible reasoning matches my experience with it too.

On hooks, I'd agree with talking yourself out of it. Your UDEV_RULES conclusion seems like the right instinct in general, promoting it to a proper config item is clearer than a hook, and hooks tend to become the place where the hard cases go to hide.

I mainly wanted to throw the mise features out there as food for thought, not to argue for them. Happy to leave it here.

[nickjj]

I do like mise is trying out new things though.

It all comes down to configuration management in the end, because there are 2 different levels of abstractions at play here. There's the personalized opinions and there's setting up the files and state related to those opinions. It makes sense to try and build a framework or system to let you apply your opinions in an easier way.

Whether you use bespoke shell scripts, Ansible, mise or something else is up to you. It's a game of trade offs.