It's fun to see package management improvements move full circle—lessons from Ruby package management contributed to Rust, Rust is helping improve package management for Python, and now Python package management is inspiring improvements for Ruby!
On the one hand, it's nice to see Ruby and the Ruby tooling system getting some love.
On the other, I'm not sure if this is really needed. Most of this stuff already works fine in Ruby with Bundler. Did you know that Bundler already has a really nice syntax for inline requirements for single-file scripts?[0] Seems like a lot of people forgot. Installing Ruby hasn't generally been much of a hassle either AFAIK. Bundler also doesn't seem to have the Python venv problem - it works fine for keeping a bunch of gem versions around in the same Ruby install and only activating the specified ones. I think Gemfile and Gemfile.lock is what Python always wished they had. I guess more speed never hurt, but it never felt like bundler was painfully slow for me, even on huge codebases. So is there really a big win here?
Though I guess plenty of Python gurus probably feel the same way about the uv craze when their existing tooling works well enough for them.
I agree mostly, though I guess it is easier for newbies if they only have to learn one tool instead of three more focused ones (bundler/chruby/ruby-install in my case, but the latter two have mostly equivalent variants).
As someone who uses Nix and direnv to manage development environments, the additional speed will be nice for me. I don't need rv to supply a Ruby for me at all, but just a really fast Bundler would be nice.
My environment reasserts that the correct things are installed every time I change into the directory. A no-op Bundle install takes a couple hundred milliseconds, which is not great for something you want to run constantly and automatically. Getting that down to tens of milliseconds will be really nice for me!
It looks cool but I feel this kind of tool is only useful if Ruby is the only language you use. I have to manage several runtimes for most projects. I've used asdf for years and recently switched to mise: these tools already download pre compiled binaries for Ruby, plus pretty much any other language runtime.
It's likely that you get better per language features for something specific to the language though. We end up in exactly the same kind of frustration, that for some random project you need this specific tool that does dependency management of the specific runtime. asdf and mise both respect a .tool-versions file, I'd rather see things go more in that direction with some kind of standard.
A flake.nix file plus a direnv `.envrc` file with `use flake` has solved this for me.
When I cd into a project directory I get all of the tools that project needs, at the exact versions they were tested with. When I cd out of the directory, they go away. If the dependencies are well behaved (e.g. they don't do any self-modification, which is annoyingly common in the npm world) then it's often pretty easy to track all of your deps this way, imported from your npm package-lock.json or similar.
Ask your favorite LLM to write your flake.nix file for you, they're pretty good at it. I've been able to drop all of the bespoke language-specific tool versioning stuff `nvm`, `uv`, `rvm`, etc for all my personal projects, and it makes it easy to add deps from outside the language-specific package managers, like ffmpeg and lame.
If you still want to package your stuff natively for the language ecosystem, you still need all the usual metadata and you also want to specify version constraints for your dependencies and so on.
Typically I wire up something like uv or rv (or Poetry or Bundler, which are fine but slower) to shell activation using Devenv, then autogenerate the Nix package from the language-native dependency specification files.
mise is really nice in this respect in that it manages the tools and the environment, so you don't need direnv as well. It also has hooks for running arbitrary commands when you cd in (although you can do that with direnv because it basically just runs .envrc as a script).
mise uses `uv` as a backend for some python things (like python tools via `uvx`). If `rv` develops in the same direction as `uv` then it could be the default backend for `mise` ruby things.
I've been very happy with `mise` since switching from asdf, and also very happy with uv in general. I think they play nice together.
I agree with the sentiment as I also use asdf but feel at this stage this critique of the project feels more than a little unfair.
We really don’t have the features they’ve been discussing including the npx like feature and easily just run Ruby without installer headaches that it seems they’ve gone after solving.
Reframing, id like to ask that .tool-versions be supported as a place where we can define Ruby versions. Then both tools with a little tweaking could pretty much be used side by side.
I don't think I really criticized the project. I said it was cool, I had a look at it. I just put down that I think there are pros and cons to the single language approach and, for me, the cons outweigh the pros.
Wait, how do you get precompiled Rubies with mise? I still have to compile with default settings, and the docs only mention that it uses ruby-build behind the scenes: https://mise.jdx.dev/lang/ruby.html
I don't think you can. I also don't know why people care so much about it - I work full time with ruby and compiling a new version, which maybe takes 10 minutes, a couple times a year is no big deal.
One thing I love about Ruby is it never devolved into ?VM hell like Python did. Yes, there are a bunch of ruby version managers, but there's only one bundler no matter how you get get ruby installed. I like some ideas here, but I'm also afraid this could be step one toward that python nightmare.
It seems pretty different in that rv waited to take inspiration from a relatively clear winner in an entirely different ecosystem, after quite some time. I think it makes sense to be optimistic.
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?
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.
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.
I think it's probably for the best to have a different tool for each language/platform. Not every language or platform matches feature for feature in that the options will already be different for each language, and you're likely to have such a "universal" tool come up short in support of one language or another.
I really appreciate cargo a lot for what it brings, even if it's calling different tools under the covers. Similarly, I appreciate deno in that it brings all the tooling and the runtime in a single executable (box). I've migrated most of my scripting to TypeScript using deno at this point because of that distributive ease. Even if the shebang itself is a bit sloppy.
Aside, would be cool to have a VS Code extension that would to file type detection based on a shebang at the top of the file. Making it easier to do extensionless script files with language support.
In theory it would be nice to have one tool for all languages but I think it's never going to be practical because programming languages can be different in arbitrary ways. I can't imagine how the same tool could ever be ergonomic for managing projects written in C++, Scheme, Haskell and Bash for example. Mise (and other tools for managing development environments like Flox and asdf – I prefer Flox myself) only implement a subset of the features of languages specific tools like cargo/uv/rv. For example cargo can do all of this out of the box (and you can also extend it with more subcommands):
* manage dependencies
* format and lint code
* publish package on crates.io
* open the project documentation
* install binaries
* build/run the project
* run tests
* run benchmarks
Uv/rv don't (yet?) do all of that but they also manage Ruby/Python versions (which is done separately by rustup in Rust).
What is the real problem being solved here? For all the issues that bundler still has, rv doesn't seem to address most of them. Bundler has been fast enough for a while now, how fast does this need to be? And do we now have to know rust to contribute?
If indirect is salty that the rubygems/bundler didn't turn out yet to be what he wanted, I wonder whether a simpler and faster alternative to bundler written in RUBY wouldn't be the answer, with incremental merges into bundler. Gel was mostly there, even if most never knew about it, but at least it got the bundler ppl to merge the pub grub resolver.
This looks like a really nice improvement to the Ruby ecosystem. Great job and thank you to those involved.
I've definitely felt the awkwardness of gems being so compartmentalized by project that using system level dev tools that I like to have available for all my projects feel out of place within my project's Bundler-centric world.
> We expect to be able to silently run equivalents of both rvm install and bundle install at the beginning of every bundle exec,
Do I understand right it doesn't use bundler code for resolving gem requirements dependency tree, but uses it's own code meant to be compatible? Hmmm.
And also producing the `Gemfile.lock`, which has had kind of a lot of churn in bundler, which bundler has had to work to keep from breaking for people even when it's assumed they're all using (different versions of) bundler.
I remember bitching to André at a conference that the Gemfile.lock format was a right hassle to deal with for literally any other tool, before I realised he was bundler maintainer at the time...
Readit News
On the other, I'm not sure if this is really needed. Most of this stuff already works fine in Ruby with Bundler. Did you know that Bundler already has a really nice syntax for inline requirements for single-file scripts?[0] Seems like a lot of people forgot. Installing Ruby hasn't generally been much of a hassle either AFAIK. Bundler also doesn't seem to have the Python venv problem - it works fine for keeping a bunch of gem versions around in the same Ruby install and only activating the specified ones. I think Gemfile and Gemfile.lock is what Python always wished they had. I guess more speed never hurt, but it never felt like bundler was painfully slow for me, even on huge codebases. So is there really a big win here?
Though I guess plenty of Python gurus probably feel the same way about the uv craze when their existing tooling works well enough for them.
[0] https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
Ruby/Bundler doesn’t have any of these problems, and nothing on their roadmap really excite me.
Except maybe the binary Ruby distribution, but it’s a once or twice a year thing, so not exactly a major pain point.
My environment reasserts that the correct things are installed every time I change into the directory. A no-op Bundle install takes a couple hundred milliseconds, which is not great for something you want to run constantly and automatically. Getting that down to tens of milliseconds will be really nice for me!
It's likely that you get better per language features for something specific to the language though. We end up in exactly the same kind of frustration, that for some random project you need this specific tool that does dependency management of the specific runtime. asdf and mise both respect a .tool-versions file, I'd rather see things go more in that direction with some kind of standard.
When I cd into a project directory I get all of the tools that project needs, at the exact versions they were tested with. When I cd out of the directory, they go away. If the dependencies are well behaved (e.g. they don't do any self-modification, which is annoyingly common in the npm world) then it's often pretty easy to track all of your deps this way, imported from your npm package-lock.json or similar.
Ask your favorite LLM to write your flake.nix file for you, they're pretty good at it. I've been able to drop all of the bespoke language-specific tool versioning stuff `nvm`, `uv`, `rvm`, etc for all my personal projects, and it makes it easy to add deps from outside the language-specific package managers, like ffmpeg and lame.
Typically I wire up something like uv or rv (or Poetry or Bundler, which are fine but slower) to shell activation using Devenv, then autogenerate the Nix package from the language-native dependency specification files.
Flake.nix is nix specific I would guess?
Mise is way easier.
It also brings awesome task files... With it's usage lib
I've been very happy with `mise` since switching from asdf, and also very happy with uv in general. I think they play nice together.
We really don’t have the features they’ve been discussing including the npx like feature and easily just run Ruby without installer headaches that it seems they’ve gone after solving.
Reframing, id like to ask that .tool-versions be supported as a place where we can define Ruby versions. Then both tools with a little tweaking could pretty much be used side by side.
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?
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.
I really appreciate cargo a lot for what it brings, even if it's calling different tools under the covers. Similarly, I appreciate deno in that it brings all the tooling and the runtime in a single executable (box). I've migrated most of my scripting to TypeScript using deno at this point because of that distributive ease. Even if the shebang itself is a bit sloppy.
Aside, would be cool to have a VS Code extension that would to file type detection based on a shebang at the top of the file. Making it easier to do extensionless script files with language support.
* manage dependencies
* format and lint code
* publish package on crates.io
* open the project documentation
* install binaries
* build/run the project
* run tests
* run benchmarks
Uv/rv don't (yet?) do all of that but they also manage Ruby/Python versions (which is done separately by rustup in Rust).
If indirect is salty that the rubygems/bundler didn't turn out yet to be what he wanted, I wonder whether a simpler and faster alternative to bundler written in RUBY wouldn't be the answer, with incremental merges into bundler. Gel was mostly there, even if most never knew about it, but at least it got the bundler ppl to merge the pub grub resolver.
I've definitely felt the awkwardness of gems being so compartmentalized by project that using system level dev tools that I like to have available for all my projects feel out of place within my project's Bundler-centric world.
Do I understand right it doesn't use bundler code for resolving gem requirements dependency tree, but uses it's own code meant to be compatible? Hmmm.
And also producing the `Gemfile.lock`, which has had kind of a lot of churn in bundler, which bundler has had to work to keep from breaking for people even when it's assumed they're all using (different versions of) bundler.