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.
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.
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
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.
This is cool! A frequent problem I've had with bundler is when the Gemfile lists a newer version of a gem (stringio) but the older version has already been activated. If you can get rid of such errors I would be so happy! Also I've had to frequently update bundler too often when updating a Rails site.
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.
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.
Or you can use a nix wrapper like jetify's devbox.
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
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.
fast installs will be great. compiling ruby is the only slow part left in our provisioning process.
This is cool! A frequent problem I've had with bundler is when the Gemfile lists a newer version of a gem (stringio) but the older version has already been activated. If you can get rid of such errors I would be so happy! Also I've had to frequently update bundler too often when updating a Rails site.