I've used asdf for years, but recently switched to https://github.com/jdx/mise
It's a drop-in replacement for asdf, but I prefer some of the nice features it has to offer.
People will generally change taste and likes/dislikes every few years.
asdf hasn't just started getting popular. It's been popular for a long time already. IIRC I started using it ~8 years ago (~2016). asdf has been around since 2014. I believe Mise (rtx) has been around for a couple of years already too.
Also, contrary to the other comments in this chain I don't find it particularly slow..
I identified [0] the source for much of it (sub-shells and pipes) and began a PR [1], but became bogged down with BATS testing, and then found mise / rtx, so kind of lost interest. Sorry. You can always implement these if you’d like.
[0]: https://github.com/asdf-vm/asdf/issues/290#issuecomment-1383...
Where-as asdf creates shims that go into the PATH. That way any processes launching processes using normal env rules have asdf applied.
Mise looks well built & is very fast. But it's jaw dropping to me that it's coverage is so drastically lower than asdf.
I switched from asdf to mise and everything works fine _if_ you setup shims.
The main differences are better UX with simpler commands and it not using shims, which means much better performance
Solutions considered include adopting the vfox plugin system or transpiling all asdf plugins to ShellJs.
Now I know that vfox exists.
It'll be a long road ahead and I could certainly use some help if anyone out there is interested in moving it forward. That said, vfox is a really great project and they are targeting windows specifically. Windows will probably always be second in the mise ecosystem (because I don't use it) but my hope is I can get at least a baseline of support which would help teams that have occasional windows contributors.
It sure is great, it is! However, like you, I tend to prefer minimalistic and predictable tools.
That's why I decided to add the small comment in the discussion section of the post, to be fair but also kind of clear that bloating the runtime manager that was supposed to help manage the bloated runtimes and package managers isn't a great idea.
Having said that, if the scope of mise stabilizes and it doesn't turn into a kitchen-sink kind of project, it sure seems sweet!
However, it turns out that a tool that needs to be extremely CWD-aware also makes a great .env tool and task runner. I was also a little skeptical, but it’s actually super super useful. Especially because it’s easy to convince team members to install it for the tools, they get the rest for free with easy syntax.
In the future though I see tasks as being the headline for mise over tools. That's a ways out, certainly more than a year, but the thing about tasks is they don't suffer from the drawbacks that both PATH and shims have for putting your tools in the right place. In my personal use of mise I don't actually like using `mise activate` whatsoever. The problem is just that I can't yet do everything with tasks easily enough. Tasks need to get to a point where they're so easy you won't want to bother with having tools in your shell.
Though who knows. I may be off my rocker on that one. I certainly get things wrong as much, if not more, than I get them right.
That said, I think if you thought about _why_ you like minimalistic and predictable tools you may find that mise solves the underlying reasons for that. My whole thing is about augmenting your environment and not replacing it. This is generally where I contrast mise with tools like nix and docker but I thought it was worth calling out.
I think people like mise because they can use it for just setting some env vars, installing a few npm packages globally, having an easy way to synchronize tool versions between local dev and CI/CD. You can use it for any one of those things and it slots right in wherever you are—whether that's inside VSCode, ssh'ed into a remote machine, in a github action, or inside a docker container in a k8s fleet.
Yeah mise is capable of a lot of different things, but the important thing is that it doesn't force you to change anything _else_ about your setup.
Why is it based on the Conda ecosystem? Do you happen to know?
I assume it's for portability, but that sounds heavy.
My org does a lot of work combining machine learning with oceanographic and climate modeling, which are both domains that have deep dependency chains that don't always mesh well, especially as our researchers mix in R and other languages as the same time, and the Conda ecosystem helps us a ton with that, but there are issues that `conda` and `mamba` don't help us out with.
Pixi takes a swing at some of what the Conda ecosystem hasn't been great at (at least without a lot of manual custom ceremony) that Cargo, Poetry, Pipenv, PDM, and other dependency and workflow management tools have demonstrated can be done such as lock files, cross platform dependency management, task running, and defining multiple related environments.
What's really cool when you have a mix of projects, Pixi can work almost entirely PyPI native out of a `pyproject.toml`, other than installing Python from Conda-Forge, so you can mix and match environments but stay with the same tool. https://prefix.dev/blog/using_python_projects_with_pixi docs: https://pixi.sh/latest/advanced/pyproject_toml/
asdf handles tools, not really packages. So asdf would install Python and not Python packages.
asdf.vm together with pipenv is my go-to for Python environment management.
[0] https://pip-tools.readthedocs.io/en/stable/
As for Poetry, it is constantly improving and has gotten very popular. It should not be dismissed, especially for larger projects since its dependency management is so much better than pipenv. This is a good primer: https://diegoquintanav.github.io/poetry-primer.html
I think it’s fair to see appeal in poetry, but ultimately the maintainers have created a culture that feels a bit too non-collaborative to outside ideas or use cases beyond what they more narrowly envisage. That said, my perspective may just be tainted by multiple poor experiences interacting with the maintainers.
then you'd also need rbenv, nvm, etc.
and pyenv can implode in marvelous ways.
pyenv isn’t perfect, and isn’t what I’d use for prod images, but for dev setup it’s relatively bulletproof and less issue-prone than any alternative I’ve seen.
The other 2 reasons are more subjective. The first being I've had less issues installing packages with PDM. It's been a while and I don't remember which specific packages Poetry struggled to install, but my takeaway was just that I don't run into those problems with PDM the way I did with Poetry.
The other larger/more consequential reason is the maintainers of Poetry. There have been a number of GitHub issues replies laying out plans for things they will/won't do with Poetry, and it didn't inspire confidence in me. I want to do things the "Python way," not the "Poetry way," and PDM adheres more closely to the direction the Python project is moving. I don't want surprises later down the road when a tool (Poetry) is doing a bunch of custom stuff that eventually may not be compatible with the ecosystem at large.
All that being said, I had a lot of good things to say about Poetry while I was using it, and I do understand why people make it their package/project manager. Just wasn't the right fit for me.