I just discovered it this morning and it works like a charm as an asdf replacement for my Python setup at work.
It also replaces "just" as a task manager for me which is very pleasant.
The fact that the python plugin uses precompiled Python binaries by default instead of building them from source remove common issues I had with the asdf's python plugin at work with missing dependencies.
Just so you know, I encountered two little quirks that needed a fix:
That issue is a real bear right now, probably our top problem. Feedback on precompiled pythons has been super positive and in fact the top feature request I've had several duplicates for is the ability to _force_ mise to use the precompiled binaries. If anyone thinks they can crack our portable pythons running poetry I'll buy them a steak.
It is funny to me something can so well liked while also causing a lot of problems. Maybe not too dissimilar from the whole rtx -> mise debacle :p
Tbh I don't find their comparison to asdf particularly compelling. While the asdf shims have downsides, besides that I think I prefer the more principled and tightly scoped approach that asdf has.
> mise makes heavy use of aliases so you don't need to remember if it's mise plugin add node or mise plugin install node. If I can guess what you meant, then I'll try to get mise to respond in the right way.
I prefer that there is one, correct, way of doing things and my tools not trying to guess what I want. If there are two different commands they should do two different things and it should be clear what the difference is. Keeping track of different aliases is just additional mental overhead to me.
I acknowledge that all this is very much a preferential thing, so I guess if this works for author then more power to them.
If you use asdf, I would encourage you to try my tool. A lot of the work I've done is around things that you probably won't ever think about but in mise it just works the way you want it to so you can get to getting your work done.
The reason people like mise is hard to put in a post because its really the care and countless hours I've put into working through workflow after workflow over and over. Testing things out. Going back on decisions I felt like weren't as good as they could've been. Reading and re-reading code in both my own codebase and asdf's. My niche is building CLIs and I am grateful to be able to work on something people are finding so much value in. Understand mise didn't start last year, I've been planning this project for over a decade while working on other CLIs and dev tools.
Here's an example of one: in mise the shims will fall back to system versions. So if you have a shim for `ruby` but you only use ruby in 1 project without a global set then calling ~/.local/share/mise/shims/ruby will go to the next thing on PATH, so maybe /opt/homebrew/bin/ruby. In asdf, the shim will fail outright unless you explicitly set "system" as the version in your global config.
At the end of the day though, I know not everyone will like mise. I certainly have a particular style of building tools and managing the project that works for some and doesn't for others. Ultimately I think this allows me to build tools that while they may never be universally adopted will be more enjoyed by those that it rings true for. Of course if you don't like it I'd be particularly interested to hear what is is you don't enjoy.
You don't need to keep track of aliases, can just as easily use your "one correct" way and never learn/forget the alternatives, so what's the downside? In general, the overhead of remembering precise tool-specific command is higher that using some common knowledge from other tools you remember that are aliased in this tool
> You don't need to keep track of aliases, can just as easily use your "one correct" way and never learn/forget the alternatives, so what's the downside?
Sure if you work in an isolated bubble and don't ever read the docs, google things, discuss with other people (or llms I suppose these days). But that's not really realistic... In practice you will be encountering the variations all the time, and it'll just add friction.
> In general, the overhead of remembering precise tool-specific command is higher that using some common knowledge from other tools you remember that are aliased in this tool
As polyglot developer I simply don't find that to be the case, small syntax differences are not problem, its far bigger problem when I read the docs and see five similar commands and need to figure out if they are aliases, if there are some subtle differences, and if one of those is the canonical choice.
> people (or llms I suppose these days). But that's not really realistic... In practice..
In practice it's trivial to avoid llms and stuff for such simple tools, `tool -h` is pretty often more than enough. This isn't your generic git cli monstrosity
> small syntax differences are not problem
And this discussion is not about small syntax differences, so this isn't relevant. I was talking about your ability to guess a command because that's the command you use in another tool, e.g., use "install" and not get an error because there is only 1 "correct" way to "add"
> bigger problem when I read the docs and see five similar commands and need to figure out if they are aliases, if there are some subtle differences
or "figuring out" could be as big a problem as simply reading a 5-word sentence till the end "install ... [aliases: i, a]", so this makes no sense as a general point.
> and if one of those is the canonical choice.
why would you care about canon instead of using the one best for you? If in your mental model apps are (un)installed, so you always use `tool u/i`, why would you care if the author thinks add/remove is best?
From my limited experience, python version management is crazy!
I've written medium sized personal python projects. I wasn't so concerned with reproducibility (and I didn't want to bog down my progress) but I still had to write startup scripts that would set up the environment correctly or I would be bit by something unexpected.
I write this from the perspective of a multi-decade c and c++ developer, take this for what you will.
If you find the python specific tooling too weird just use OCI containers. The packaging and runtime is isolated enough you shouldn't run into dependency or installation issues.
I was actually thinking today that shims and PATH at the same time might be the best of both worlds... though that's just a funny thought exercise I'm having right now. If some brave soul is out there and wants to experiment, please let me know how it works out :)
So yes, mise does not use shims. It only manipulates $PATH. I did benchmarks a while ago and that definitely and consistently has shaved some milliseconds off of the startup times of my tools.
You may have out of date information there. Mise was previously jdx and it used to use some of asdf plugins directly. Most of those have now been replaced by built in mode plugins for the popular runtimes. I believe it still has the option to use asdf plugins if you want to though.
I switched from asdf to mise after a comment on lobste.rs[1] suggested I do so a few months ago, and I have been very happy with it.
It sands off some of asdf's sharp UI edges and provides a somewhat larger but still reasonable feature set; I've also replaced most of my direnv[2] usage with it.
Haven’t installed it yet but this looks fantastic. The combination of tools, env, and tasks is a perfect magic trio of things almost every dev machine needs. The author has done a great job of addressing a need while keeping things simple, it’s clear that this is a useful tool that knows how it fits in.
I’ve been using mise for a few months, it’s great. I got into it when I was looking for a way to consolidate my collection of dev tools including pyenv and jabba; I found that sdkman didn’t work out of the box for me for reasons I never bothered to figure out, and it’s basically a superset of the features of asdf.
i've been using this for several months to manage python, rust, flutter, and go projects. one of my favorite features is automatic entering of python virtualenv (without spawning a subshell) when config contains `python = {version=..., virtualenv=".venv"}`
it has been working very reliably, though offline users should be aware of default network timeout which can affect user experience when entering a mise configured path (see `MISE_FETCH_REMOTE_VERSIONS_TIMEOUT=0s`)
my biggest complaint is a philosophical one. it conceptually becomes a distribution package manager, which leads me to think of tools like (nix-based) devbox and devenv which ar more holistically designed and can manage service infrastructure as well.
this is a use-case I should be more thoughtful around. I do try to never ever block on HTTP for anything where you aren't explicitly calling mise—so like `mise ls-remote` obviously is going to block, but if mise is just running to update PATH behind the scenes it should never, ever cause any significant delay. If you ever see this happen try to let me know—though I understand that by its nature that can be a very difficult thing to reproduce.
> conceptually becomes a distribution package manager
I talk about this a lot in private but I don't think it's in any docs but this is expressly not something I would ever do. Mise stops at your system. I'll never try to install openssl or something to patch your system or get libraries in place. Nix is the tool for people that want that sort of thing.
IMO the biggest competitor to mise isn't asdf, it's nix and docker and mise is the polar opposite of both. That's not to say those tools don't have their place but at their core: docker and nix try to _bypass_ your environment by building their own. Mise augments your environment which means you don't need to figure out how to get stuff into or out of the environment. You environment is what it was before, just with tools, env vars, and tasks to make working in that environment easier.
However yes, this does mean you may be missing a shared object from time to time. Or need to install libxml. But at least you don't need to setup rsync.
No, mise is compatible with asdf plugins, but it is its own implementation. If the plugin uses pyenv (I believe the python plugin does) then it will use that. But otherwise it's not a wrapper. E.g. the asdf golang plugin downloads the files from https://go.dev/dl/. It entirely depends on the plugin itself.
The fact that the python plugin uses precompiled Python binaries by default instead of building them from source remove common issues I had with the asdf's python plugin at work with missing dependencies.
Just so you know, I encountered two little quirks that needed a fix:
- "Backspace Key Doesn't work in Python REPL": https://github.com/indygreg/python-build-standalone/blob/mai...
- An issue with the mise-poetry plugin: https://github.com/mise-plugins/mise-poetry/issues/9
I will see how it goes in the long run, but I really like it so far :)