jdxcode

That’s not true with mise. You can add something to the front of PATH in front of mise bins and mise will respect that.

CodeRabbit's support for mise is greatly appreciated, not only do i depend on CodeRabbit for code reviews but CodeRabbit is also a partner level sponsor for mise and my other open source work: https://jdx.dev/sponsors.html

thanks so much!

i benchmarked it locally a few weeks ago and it's much faster than homebrew 7

how much faster is kind of a useless metric: it's so highly variable on which command and things like network speed, expect 2x-1000x faster depending on what we're talking about

someone should make flattendallas.com as a joke

also the repo needs 500+ stars https://docs.github.com/en/communities/documenting-your-proj...

i was going to say the biggest reason wasn't mentioned here, that github sets Disallow: /*/wiki*

however I think maybe this has changed? I don't see it in https://github.com/robots.txt now

i just tested and `mise bootstrap` is over twice as fast at installing when a bottle was in the cache. other commands like `status/check` are 20-30x faster. that's without spending much work at all on perf—i'm sure i could bring these numbers down much further.

Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project

no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)

this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.

i thought the same thing but i bought a model y a few months ago and turns out that's exactly what I want. 90% self driving and really the 10% is entirely the last part of a drive because it picks stupid parking spots and doesn't know how to enter my driveway, other than that it's driven perfectly

well, perfectly is a bit much, it doesn't know how to dodge potholes yet and it sometimes misses exits/turns, but it's never done anything i would call dangerous

for skills related to specific cli tools, i just wrote a standard for this! it's obviously not widely used yet, but since mise will support installing the skills alongside the tool, i suspect it will have decent adoption

i used to be a bit bearish on skills—thinking that llms should just use --help, but i've come around on that. i think skills are a great way to describe higher level workflows that use multiple commands.

https://jdx.dev/posts/2026-09-05-introducing-packslip/

I'm biased but I think it's silly to think either one is going away anytime soon

well mise uses dotenvy right now (for env._file anyhow), it may be worth switching to dotenv-ng but I haven't looked into it yet https://github.com/jdx/mise/blob/fc441787fe52b46be1245046758...

I assume you just mean normal [env] in mise.toml which is different, but this still is relevant to mise

90% of australians live in 0.22% of the country's land

i think that sentence is taken out of context a bit, the problem with those pkg binaries is that they're not portable—which the post describes

EDIT: actually no, I think charlie is wrong on that point, he said the installers compile python but that only happens with python-build-based installers like pyenv. still, the fact those binaries lack portability is the real problem.

mise uses these as well and adopting them has been a massive improvement in the user experience for my python users. y'all have been doing a fantastic job maintaining them.

i'm also doing the same for ruby—maintaining the binaries myself which is becoming the default in mise next week: https://github.com/jdx/ruby

i'm a firm believer that pre-compiled, portable binaries are the best way to distribute runtimes and clis.

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.

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.

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

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.

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.

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.

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

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

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.