Comment by PufPufPuf

3 days ago

I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dynamically adjust which ones are active per working folder or explicitly through environments.

Funnily Mise does not support dependencies, and I was quite surprised that it mostly doesn't matter, as either pnpm/uv handles that, or it's a static binary that just works. In the past, had the unfortunate experience of packaging a Python application for Homebrew (the ridiculous process involved importing around 50 dependencies as "resources", building every single one from source or manually checking if it's already on Homebrew, declaring build toolchains for 5 different programming languages as dependencies, waiting over an hour for CI to finish on every update, then an upstream update introduced a "build-time dependency loop" and the project suddenly became unpackable for Homebrew) so I totally get why Mise took the "easy way out" and just relies on language-specific package managers directly.

Only thing from my Brewfile that I couldn't replace was the Docker CLI (needed to interact with Colima). And I still use Homebrew for casks. I encourage others to experiment with their dev setups, there are some amazing new tools out there.

58 comments

PufPufPuf

Reply
thatxliner  3 days ago

Glad you're having a good experience, but I personally switched from Mise back to Brew. I don't know if it was just my skill issue, but there were too many packages which found Mise to be problematic.

chuckadams  3 days ago

As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).

jdxcode  3 days ago

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.

  • tempusfrangit  2 days ago

    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.

zchrykng  3 days ago

I like mise a lot, but only use it for project specific tool management, JDK versions, etc.

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.

  • jeremyjh  3 days ago

    mise use -g ripgrep@latest

    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.

  • PufPufPuf  3 days ago

    For system-wide things I usually use "latest" but it's nice being able to downgrade and/or stick to a working version using lockfiles. I remember back when I used Homebrew, Teleport shipped a bug that prevented me from accessing our servers and downgrading was a pain.

port11  3 days ago

Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox.

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.

  • ricardobeat  3 days ago

    What do you mean by that? If you have mise activate set up correctly in your shell rc file, globally installed tools are available in every shell. There’s also shim mode [1].

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

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

    • port11  3 days ago

      Not an expert, but Claude doesn’t seem to be running with my ZSH profile? Really, anything that isn’t a terminal and tries to use global commands, such as utilities that expect Node to be available and so on. I always have to prefix commands, unless using the terminal myself.

      2 replies →

  • tempusfrangit  2 days ago

    I just added a post-checkout hook for my team:

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

notpushkin  3 days ago

Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit trickier – it gets installed as `docker-cli-plugin-docker-compose`, but docker-cli doesn’t seem to pick it up. I’ve added a symlink as `docker-compose` for the time being.

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

  • PufPufPuf  3 days ago

    FWIW you can replace pngpaste with a simple script: https://til.simonwillison.net/macos/impaste

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

    Thanks for the docker tip!

    • notpushkin  3 days ago

      > FWIW you can replace pngpaste with a simple script

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

      And also you can manually symlink it to the Docker plugins dir so `docker compose` works as well:

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

  • FireInsight  2 days ago

    There's the rename-exe option in mise.toml to rename the docker compose binary to `docker-compose`. I've used it on some machine, I think. Look it up in the docs, it doesn't take long to wire up.

dkarter  3 days ago

Mise does support docker cli - that’s how I use it with Colima - what’s not working for you?

  • anhner  3 days ago

    Last time I used it it was missing some features (like compose for example), but nothing a LLM can't fix (needed just some symlinking).

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

hk1337  3 days ago

I really like mise but I don’t think it’s an adequate homebrew replacement. I use it more for project management dependencies and tasks.

  • tempusfrangit  2 days ago

    100% agree. They are complimentary. Brew handles specific things far better and mise handle polygot and some things where many versions need to been handled on the same system.

    But my list of brew items keeps getting shorter.

esafak  3 days ago

Don't forget that mise depends on package registries, to install itself as well as its tools.

  • PufPufPuf  3 days ago

    Mise installs itself as a static binary actually (but it's of course packaged in many registries), and while there are some third party registries it delegates to for some packages (aqua, asfd), most stuff I have installed is either built-in, or from PyPI, npm or GitHub, i.e. directly published by the upstream maintainers. More info: https://mise.jdx.dev/dev-tools/backends/

threecheese  3 days ago

Do you have an example? Sounds interesting.

altern8  3 days ago

That's kind of weird that you're using this announcement to steer people to another project.

Or am I missing something..?