I wonder if you misunderstood what mise is based on your mention of "packaging challenges". mise deals with language runtimes and dev tools—it doesn't manage dependencies or package anything.

I often hear suspicion about mise for this reason from people that haven't used it. I suppose it's not surprising. That said, I have spent over a decade in the developer productivity space as well as hundreds if not thousands of hours working on mise in the last 2 years—if there is someone that can build this I'm probably the right guy for the job.

Particularly with dev tools, it's long been the case that mise has solved this problem. Improvements are continuing to be made with things like improving supply chain security and ergonomics with python—though it's not like the python community itself has its DX figured out.

Of course I'm still fixing bugs pretty regularly and that probably won't ever change but there are hundreds of thousands of developers out there using mise (kind of a guess, but I'm pretty sure) and it's working great for them. It's in the top #100 tools in homebrew now: https://formulae.brew.sh/analytics/install-on-request/30d/

This definitely isn't some scrappy project—I've devoted much of my life to this problem and I think all evidence points it it being a resounding success.

I think mise gets a lot right. I use it for environment variables, Python virtualenv creation and activation, and task scripts.

I've been a software developer for over twenty years and am usually reluctant to use new tools. But mise has been a fantastic addition to my dev workflow.

> Because most people barely know in depth the packaging challenges for one ecosystem.

I think you’re greatly overstating the problem, at least insofar as it relates to this tool.

For example, Python has its prefix (where packages are installed) baked into its installation. pip, ux, poetry — whatever — are going to install python packages there.

This tool is unconcerned with package installation — it is only concerned with getting the interpreters installed and managing which one is on your $PATH.

There’s literally nothing to leak.

And regarding “wraping existing tools” as proof of some shortcoming in mise (and/or similar) — if they reinvented the wheel, that’s where things could leak. And separation of concerns is a good thing.

It might be useful for you to try the tool before complaining about it

I’ve used mise for years. It works perfectly well. I use it for Go, Node, Deno, Java, Python, Ruby, and Rust.

Your experience with "such tools" covers experience with Mise, or are you just making assumptions?

My experience with Mise is that it's a great tool.

>My experience with such tools is that when you do everything, you don't do anything right.

Does it matter? Even dedicated tools don't do everything right.

As long as it does the things one wants to do good enough, and offers a cohesive interface to them...

Example: I tried to convince our deployment system to deploy patch releases to simplify our hotfix solution. The code was in Node and the deployment tool in Python. I had to thread the needle to come up with a semver pattern that was legal in both Python and NodeJS. Not impossible but annoying. (Then discovered our deployment tool wasn’t using the semver parser in Python and it still didn’t work. Goddamnit.)

> My experience with such tools is that when you do everything, you don't do anything right.

As a long time Emacs user, I agree :-)

Exactly. A task runner for Node.js is already complex enough. And it's not just a task runner itself, but rather an ecosystem of things working together. Now you tell me this can somehow handle Node.js, Python and others. I'll need to see how it actually works in the real world to believe the claim.