Rv, a new kind of Ruby management tool

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.

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.

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.

Nix is too hard.

Mise is way easier.

It also brings awesome task files... With it's usage lib

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.

devenv.sh

This is the way. Nix, despite all of its issues, is still the best for reproducible developer environments. I just don't write my own flakes anymore.

I sent jdx this article, so maybe it will happen sooner rather than later

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.

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.

I think it comes mostly from CI environments that start entirely clean before every run. 10 minutes every time a commit is pushed is not pleasant. That's not how I'd like CI to work, but sadly it seems to be the current state of things.

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).

Flake.nix is nix specific I would guess?

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.

nix manages the environment too, all direnv is doing in my setup is automatically entering and leaving environments based on my current working directory. Looks like mise does that automatically, which is neat.

mise looks nice, uses PATH manipulation rather than asdf's slow wrappers, and it supports Windows, which is a point over nix. nix only supports unixy environments like Linux, Mac, and WSL.

What might tempt a mise user to try nix are its just truly stupendous collection of packages, so more tools are available. You can also easily add your own packages, either upstream or privately. nix is bigger, more ambitious, more principled, but more complicated. You can build an entire fully-reproducible operating system from a short nix config. It's really cool! But also a lot more to learn, more surface area, more places to get confused or to spend time fiddling with configs rather than solving the actual problem.

Judging by the current project status it'll probably be a while...

(looks like they've only got installing certain ruby versions working for now.)

[0] https://github.com/spinel-coop/rv/blob/main/docs/PLANS.md

I've only used circleci and github actions for this, but in both cases precompiled rubies are available. On circleci you run your tests on a ruby docker image with the right version of ruby installed. On Github Actions I use https://github.com/ruby/setup-ruby, which installs an compiled ruby in a second or two, and also properly caches your gems. I think if someone's CI environment is building ruby from source they are doing it wrong.

Discussion in the mise discord also raised concerns about it using the homebrew "portable" rubies