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.

▲

rictic 3 hours ago | parent | next [-]

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.

▲

pxc 14 minutes ago | parent | next [-]

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.

▲

goosejuice 2 hours ago | parent | prev | next [-]

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.

▲

bryanlarsen 3 hours ago | parent | prev | next [-]

Or you can use a nix wrapper like jetify's devbox.

	▲	goosejuice 2 hours ago \| parent [-]
		devenv.sh

▲

airtonix 3 hours ago | parent | prev [-]

[dead]

▲

mijoharas 2 hours ago | parent | prev | next [-]

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.

	▲	paradox460 an hour ago \| parent [-]
		I sent jdx this article, so maybe it will happen sooner rather than later

▲

evolve2k 3 hours ago | parent | prev | next [-]

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.

▲

saint_yossarian 2 hours ago | parent | prev [-]

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