←back to thread

333 points steveklabnik | 3 comments | | HN request time: 0s | source
Show context
lutzh ◴[] No.45036598[source]
I'm sure rv is great, but am I the only one who needs one such tool not only for Ruby, but also Python, JavaScript, and Java, at least, and finds it weird to run 4+ of those?

I put my hope in mise-en-place - https://mise.jdx.dev

What do people think? One tool per language, or one to rule them all?

replies(5): >>45036709 #>>45037013 #>>45037435 #>>45037661 #>>45042085 #
1. cjk ◴[] No.45036709[source]
We've been using mise since it was called rtx at $DAYJOB, and it's caused many a headache (mostly around upgrades/backcompat/etc.). We use it both on dev machines and in CI. In spite of that, it’s decent at what it does, and I wouldn’t soon replace it with individual version managers, given that we have similar needs.

However…more than once we've seen language runtimes that used to be available exclusively via plug-ins be migrated to be internal to mise, which broke everyone's setups in strange and hilarious ways, and caused countless hours of debugging.

Less bad overall than using individual runtime version managers for sure. But the next time mise costs us a bunch of hours fixing multiple engineers' setups, I intend to find another solution, even if that means writing my own. It’s burned us nearly one too many times.

replies(1): >>45037125 #
2. paffdragon ◴[] No.45037125[source]
Do you have any examples what tends to break? We used pyenv/rbenv/sdkman etc. individually, then moved to asdf and now arrived at mise. Not using yet for CI just developer stuff and so far didn't have issues. But this is quite recent for us, so didn't have to deal with upgrade issues yet.
replies(1): >>45037436 #
3. cjk ◴[] No.45037436[source]
We manage mise itself via homebrew. Sometimes when upgrading mise itself, it doesn’t seem to handle being upgraded gracefully, and loses track of installed runtimes even if we manually kick it in our upgrade scripts. Restarting the shell entirely seems to be the only way to fix it.

That, and with Ruby, Node, and at least one other language/tool IIRC, when support for those things moved internal, we had to make a bunch of changes to our scripts to handle that change with effectively no warning. That involved checking to see if the third-party plug-in was installed, uninstalling it if so, and then installing the language based on the built-in support. In the meantime, the error messages encountered were not super helpful in understanding what was going on.

I’m hopeful that these types of issues are behind us now that most of the things we care about are internal, but still, it’s been pretty annoying.