[jdxcode]

It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html

It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd.

EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend checking it out.

[0cf8612b2e1e]

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.

Edit: The docs on this are very encouraging! However, it is not clear- what is experimental? Anything notably buggy or churning? Any far off features you hope to implement some day?

[jdxcode]

ALL mise features are experimental until the design is finalized. I don’t do breaking changes except in exceptional circumstances with a long procedure, so experimental means I have the liberty of making them in any release. It is not at all any marker of quality. That said, in practice I don’t make them often.

I’d argue it’s a good time to play with features since if you have any ideas on how it might better fit your workflow I still have the ability to change the design before it’s largely frozen.

[throawayonthe]

i would reach for atomic fedora personally, maybe with bluebuild

[0cf8612b2e1e]

That still feels like more external tooling, plus letting the distro make my packaging decisions. I am already using mise, so this is an almost free boon without more complexity.

[sharts]

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).

[jdxcode]

it's dependency free. You don't even need brew to install brew formulas.

The "exception" to that are linux package managers like apt-get and dnf which it calls under the hood. I think can't be an actual issue since it's not like you would ever use ubuntu/redhat without their system package manager installed.

[frangonf]

I saw it the other day in the release notes and I'm definitely setting this up since I already use mise for many of my global tools and projects.

Some months ago I ported part of my git bare repo to chezmoi but never really picked it up since, even if I see it as a great and very complete tool for managing complex dotfiles, I don't have many machines and can live by with a bunch of if uname -s, and the fact that I still need to wrangle brewfiles and scripts for packages. Having the sytem package managers glue along the configs and symlinks is exactly what I wanted.

[halostatue]

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.

[jdxcode]

Haven't looked into it but agents are so good at this I bet it'll be trivial to add

[theshrike79]

I was just wondering if I could replace my personal Ansible setup with something simpler and now you dropped this.

Perfect timing, I'm already 80% done with the transition :D

[codethief]

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.

[jdxcode]

The problem with mise managing its own version is perf. I don't want a shim that has to read config files to exec the right version.

I would make use of min_version. It's not perfect, but will at least help bring laggards along.

[codethief]

That makes sense! I wasn't aware of min_version for some reason, thanks so much!