I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos

I agree that it sucks not being able to have comments in package.json, but I think it's the right call to not adopt something like jsonc. It would break so much tooling at this point I don't think it would be worth it.

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

why not both?

I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm

how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?

"real" meaning truly reproducible and not brittle.

Its the only complete, reproducible, and portable solution, in my opinion.

I like mise, but at the end of the day some programs are more complex than just pulling a precompiled, dynamically linked binary and hoping it works.

I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager)

I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.

I'm saying that I value the completeness (thoroughness may be a better word) as well as the reproducability and portability that nix ensures over convenience. I cant tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another.

Also noting that I don't see the problem as "dotfile management" but as "system AND user configuration management" which extends beyond some plain text files in $HOME.

ed.: and home manager is just one tool which provides not only dotfile management, but drvs for installing particular programs and configuring then in highly opinionated ways -- I do not use it

> I can't tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another.

This is a serious problem in Nix too. I often trip over buggy and abandoned Nix packages. Nix often makes it easy to roll back or work around them, but they're absolutely there.

They still build though. No one said anything about Nix being a solution to buggy software or bad maintainers, that's an absurd expectation.

Considering nothing in that reply criticized nix you’re certainly wrong. I don’t hesitate to share my opinions on nix anytime (just like nix users themselves) so I’d have no reason to be coy about my criticism.

tfrancisl was polite (even though I arguably wasn’t in the beginning) so I felt it important to return the favor.

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.

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?

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.

i would reach for atomic fedora personally, maybe with bluebuild

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.

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

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.

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.

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.

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

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

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.

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.

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

mise isn't, and has the advantage that you don't need to build your own lightsaber with direnv and nix.

doesn't aqua:docker/compose just work? it does for me

Nope :-( Just tried it again, it installs and is available in PATH as `docker-cli-plugin-docker-compose`, but `docker compose` says “unknown command”. For docker-cli to pick it up, it should be in $DOCKER_CONFIG/cli-plugins/docker-compose (~/.docker by default, though I use ~/.config/docker).

rename_exe doesn’t do anything on the aqua backend either (and isn’t a documented option). I’m on mise 2026.5.10 right now though so if you fixed something recently I might be missing out!

mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")

This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.

I am a huge advocate of mise and all the en suite.

Two jobs in a row I’ve migrated most of our workflows to using mise. Thanks for the amazing work (and I finally get to sponsor the project!)

Mise and Brew are a powerful pairing.

Thank you for making Mise!

1. the supply chain attacks I've seen are naive. They just leverage postinstall hooks. Malicious code also needs to be executed, not simply installed, so it's a lot less likely that an exploit would happen compared to postinstall since it can't just be buried in a transitive.

2. aube does the same. This is an extra level of protection if you've already whitelisted a package