←back to thread

Rv, a new kind of Ruby management tool

(andre.arko.net)
333 points steveklabnik | 8 comments | 26 Aug 25 08:15 UTC | HN request time: 0.001s | source | bottom
Show context
jemmyw ◴[26 Aug 25 21:18 UTC] No.45032462[source]▶
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.

replies(4): >>45032520 #>>45032617 #>>45033002 #>>45033020 #
1. rictic ◴[26 Aug 25 21:37 UTC] No.45032617[source]▶
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.

replies(5): >>45032708 #>>45032837 #>>45033234 #>>45033990 #>>45035148 #
2. bryanlarsen ◴[26 Aug 25 21:45 UTC] No.45032708[source]▶
Or you can use a nix wrapper like jetify's devbox.
replies(1): >>45033219 #
3. airtonix ◴[26 Aug 25 21:55 UTC] No.45032837[source]▶
Nix is too hard.

Mise is way easier.

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

4. goosejuice ◴[26 Aug 25 22:39 UTC] No.45033219[source]▶
devenv.sh
5. goosejuice ◴[26 Aug 25 22:41 UTC] No.45033234[source]▶
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.
6. pxc ◴[27 Aug 25 00:22 UTC] No.45033990[source]▶
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.

7. jemmyw ◴[27 Aug 25 03:25 UTC] No.45035148[source]▶
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?

replies(1): >>45035411 #
8. rictic ◴[27 Aug 25 04:17 UTC] No.45035411[source]▶
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.