Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).

Zbar seems to provide prebuilt binaries here https://linuxtv.org/downloads/zbar/binaries/ (haven't checked it myself)

Thanks for the docker tip!

Neat! Got curious if you can do that without a temp file, turns out you can:

  #!/usr/bin/osascript -l JavaScript
  
  ObjC.import("AppKit");
  $.NSFileHandle.fileHandleWithStandardOutput.writeData(
    $.NSPasteboard.generalPasteboard.dataForType("public.png"),
  );

Edit:

> `docker compose` is a bit trickier

I’ve tweaked my setup a bit. This installs it as `docker-compose` without symlinking required:

  "github:docker/compose" = { version = "latest", rename_exe = "docker-compose" }

  DOCKER_CONFIG="${DOCKER_CONFIG:-$HOME/.docker}"
  mkdir -p "${DOCKER_CONFIG}/cli-plugins"
  ln -s "$(mise which docker-compose)" "${DOCKER_CONFIG}/cli-plugins/docker-compose"

The default docker-compose definition comes from aqua:docker/compose though, which does not support rename_exe. You have to specify github:docker/compose instead.

Or am I missing something..?

Just downvote and move on.

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.

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.

pypi, npm, and even github (through releases) are registries.

curl | sh is an anti-pattern. It passes no security check.

curl https://mise.run | sh

...which is the same way Homebrew is installed too.

Projects then have their own dependencies, e.g. https://github.com/i-am-bee/agentstack/blob/main/mise.toml

Mise also has a task runner which automatically uses correct tools. Onboarding a new team member is super easy now, they just need Mise, "mise install" and they're up.

    mise use -g somepackage --pin

    mise up -il

It's all fairly well documented here: https://mise.jdx.dev/dev-tools/backends/

I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.

I recently found mise and have become a fan as well. I have used asdf for about a decade and it supports the same .tool-versions files so initially I used it for those exact same things.

But I use four different computers for development regularly and sometimes use Codespaces as well. While syncing dotfiles handles most of my setup, it doesn't handle binary dependencies of my dotfiles - my neovim setup wants fd & rg etc. So now those go in the mise global config. I also have a global node & python along with uv@latest which pretty much covers every tool I might want to install.

I have never cared for the fact that homebrew tries to maintain shared dependencies and several upgrades have broken stuff for me.

But my list of brew items keeps getting shorter.

https://mise.jdx.dev/dev-tools/#tool-dependencies

The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.

I use Claude on a mise-powered project daily without any issues

[1] https://mise.jdx.dev/dev-tools/shims.html

These days also trivial to restart Claude ;)

`mise trust`

Resolves that trust issue right away and is scoped to your repo (not global). We also have a make setup that helps the folks still doing make things get all setup and trusted on the main work tree.

At a past job we had a local `doctor` script that did this.

But it's not "it just works" yet.