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 :)
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
> 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.
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.
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.
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?
most of the aliases are not documented for this reason
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.
And because it's written in Rust, not going to lie.
It's even said almost at the top of the README.md in the "30 seconds demo" section:
"The following shows using mise to install different versions of node. Note that calling which node gives us a real path to node, not a shim."
https://github.com/jdx/mise?tab=readme-ov-file#30-second-dem...
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.
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.
The mise -> asdf comparison page is useful[3]
Only thing is I wished it had windows support, so my (misguided) coworkers could use it too.
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.