My experience with such tools is that when you do everything, you don't do anything right.
The chances that it doesn't leak greatly the underlying abstraction and creates troubles to figure it out when it will invariably fail is zero.
Because most people barely know in depth the packaging challenges for one ecosystem. In Python there are maybe a dozen in the world that have a good hang of __all__ of it.
And the devs of this tool would need to know so many.
Of course they don't, they wrap existing tools, which implies exactly what I said above.
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 have to say, I've been reading your replies here (and your big reply in the just thread) and I'm super super impressed with your dedication to this project. I can tell just in how you write, the volume of responses in this thread, and your tone that this is a real passion project and you're deeply serious about this. I love seeing this. Thanks for your dedication!
In all scripting language, packaging problems mostly stem from bootstrapping.
Nvm shims break, python path confusion, gem installed on the wrong ruby interpretters, etc.
Maybe you managed the impossible.
But in 20 years of python I've seen only one tool doing bootstrapping in the right direction, all the other ones have failed.
So I'm suspicious of something that does multiple languages.
In the case of mise, it delegates this complexity to the user. E.g: for python, you have to know the config choices, and choose the right backend like asdf, pyenv, or indygreg.
Then you better understand the consequences of that choice.
Specifically for Python, right now, uv is showing the most promises (and mise has an uv backend, btw) for bootstrapping.
They have carefully avoided 90% of the mistakes of all other tools, and I have a long list. They don't live in a bubble.
uv still has problems (like indy greg builds not having headers) and it's still below v1 so I can't recommend to use it yet. But I've been testing it in different contexts for months now, and it's doing exceptionally well.
I usually take a year of testing before recommending a tool, because I need to see it in action in Windows shops, in Unix shops, with beginners, with non coders, with startup, in a corporate settings, with grey beards, etc. Python versatility means the user base is extremely diverse and you find it in the weirdest envs.
and it gave me a lot of confidence that he is actually not trying to do everything at once, but quite the opposite, nail to the death very specific problems.
I've tried everything in the Python world, with a good hundred of companies envs, and about a thousand people in trainings. Pyenv, poetry, pipenv, pdm, nix, pyflow, pdm, rye, you name it.
The number of ways they can fail is astonishing.
The uv team quickly identifies when there is friction, and fix it at astonishing speed. They just announced they took ownership of the WHOLE python-build-stand-alone project, and they contribute the improvement to it to cpython upstream.
Their dedication to a good doc and great error messages is quite amazing as well.
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.
I have two problems with Mise: There isn't a page with the most common commands I might want to run, and whenever I try it, some Python imports mysteriously fail. Then I disable it, and everything is fine again.
I might be motivated to persevere if I only had one of the above problems, but with both of them together, it's too much of a hassle.
I posted an issue about the documentation and I see that it was added, so thanks! If you want, I can post more issues of the type "as a new user of mise, I expect to be able to do _______ but I can't see how in the docs". I'll also post about my Python issue when I reproduce it next.
> 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.
Bootstrapping python incorrectly is the main source of packaging problem.
There is a lot to leak. For exemple, if you install a non wheel compiled extension, you'll need the headers, but some python distro don't provide it.
Then of course, on windows, is your python registered with the py launcher? How does it interact with existing anaconda installations ? On linux on existing system installation ? Is the shim (or path update for mise) affecting /bin/env ? How that works with .pyw association ?
The. what does it implies on the venv creation and activation ? And on using -m ? And .pth files ? user-sites ?
All those questions are linked to bootstrapping.
What happens then is pip install fail or import break, but the user have no idea it's related to his bad python setup because most people don't know how it works.
And now bootstrapping has broken packaging.
This is where most "python packaging sucks" things are born: from unkowingly botching the bootstrapping.
And the vast majority of tools to do it suck. E.g: Shims are all kind of broken (pyenv and rye come to mind).
To suceed, mise would have to know all that, pick the right tool, make a perfect abstraction, create fantastic error reporting, and test all those cases on ci on all platforms.
It's possible, but I know only one project that does this almost correctly. And even this one has a long way to go.
Saying "there is literally nothing to leak" is actually perfectly making my point most people don't know the topic deeply enough to know what they get into.
Then of courses there are all the modes of failure. This article has a good bit about that:
I'm trying to use rye on Windows, but it doesn't want to use the normal installed Python version, only the versions it downloads itself, and it cannot update them easily because it pins an old one to run itself.
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.)
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.
The chances that it doesn't leak greatly the underlying abstraction and creates troubles to figure it out when it will invariably fail is zero.
Because most people barely know in depth the packaging challenges for one ecosystem. In Python there are maybe a dozen in the world that have a good hang of __all__ of it.
And the devs of this tool would need to know so many.
Of course they don't, they wrap existing tools, which implies exactly what I said above.