9 ms·

Rv, a new kind of Ruby management tool

333 points by steveklabnik 1y ago

pjmlp 1y ago
Naturally written in Rust. I could start taking bets every time I now see a "new kind of tool" for XYZ. I am firmly in the camp tools for specific ecosystems should be written on the language of said ecosystem. If one is hindered by the language, maybe that isn't the right ecosystem, or therein lies the opportunity for language toolchain improvements.
- tracker1 1y ago
  Or... rust lends itself to fast executing CLI tooling... and that no language/hammer is best when you need a screwdriver.
  - pjmlp 1y ago
    Plenty of languages do offer AOT toolchains, and CLIs have been part of computing since we have teletypes.
    - tracker1 1y ago
      In this case, we're talking about ruby... does ruby output AOT, portable executables in the box?
      - pjmlp 1y ago
        If you're willing to pay for it. http://www.rubymotion.com/ http://www.rubymotion.com/ Plus since when is AOT compilation required for CLI tools? Half of UNIX userspace would be gone.
        tracker1 1y ago
        When you're talking about portable tooling in order to install other stuff it sure helps.
        pjmlp 1y ago
        Apparently it was never a problem in the UNIX lifetime.
        tracker1 1y ago
        Yep, nobody ever, not once had trouble bootstrapping something like GCC in a new environment at all, ever.
dcchambers 1y ago
On the one hand, the ruby development ecosystem is in a much better state than Python was before uv. Bundler is way better than anything Python had before uv. On the other hand, a uv-like all-in-one for Ruby is really interesting/tempting.
1a527dd5 1y ago
Can we not have this new trend of two letter projects? It makes it super hard to Google for in the future, give it an actual name please. I don't know if the trend started with uv, but please for future engineers trying to debug/learn make it Google-able.
msie 1y ago
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.
- jacobsenscott 1y ago
  Just using `bundle exec` should handle that - that's what bundler is for.
  - msie 1y ago
    Yep, didn't work.
    - byroot 1y ago
      Yes, this is due to the effort to extract stdlib code into gems https://stdgems.org/ https://stdgems.org/ In your case, StringIO use to just be stdlib code so bundler (or rubygems) uses it. Later on it became a gem, so by requiring it before reading the Gemfile, bundler run into this problem of already having loaded the wrong version. Everytime this happens the bundler team has to modify bundler, and as a user the fix is to upgrade bundler. You can see they had to vendor a lot of code from default gems to avoid this problem: https://github.com/rubygems/rubygems/tree/c230844f2eab31478f718a80d5980a70aa6a897d/bundler/lib/bundler/vendor https://github.com/rubygems/rubygems/tree/c230844f2eab31478f...
bradly 1y ago
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.
jweir 1y ago
fast installs will be great. compiling ruby is the only slow part left in our provisioning process.
- inopinatus 1y ago
  to this end I have been deploying with the fullstaq-ruby builds for some years now.
  - jweir 1y ago
    we have investigate that, but it requires sudo access which is not allowed but the running user.
    - inopinatus 1y ago
      You may find the fakeroot utility goes a long way to help. But never forget that binary packages are merely archives, or sometimes, archives-of-archives (as in Debian); we can unroll them anywhere.
- gtirloni 1y ago
  why are you compiling ruby during provisioning?
jemmyw 1y ago
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.
- evolve2k 1y ago
  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.
  - jemmyw 1y ago
    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.
- rictic 1y ago
  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.
sleepy_keita 1y ago
I find it interesting how Rust is gaining momentum in tooling like uv and now rv.
- deleted 1y ago
  [deleted]
- inopinatus 1y ago
  Rust is the new C. Go had a shot but went in an applications direction. I predict that very soon, perhaps even inside of three decades, Rust will become the dominant, first-choice systems programming language.
  - hu3 1y ago
    Go can do just as well in tooling. Microsoft chose Go for tsc rewrite. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-... And then there's esbuild, also in Go, which revolutionized web bundling speed https://esbuild.github.io https://esbuild.github.io
    - inopinatus 1y ago
      That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point. Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.
    - tough 1y ago
      I love both Go and Rust but Go is GC no? Where rust shines is on its safety at compile time and lifetime/borrow/memory model imho both are awesome tools!
natt941 1y ago
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!
DavidCanHelp 1y ago
"Not a version manager, or a dependency manager, but both of those things and more. I’m currently calling this category a “language manager”, but if you have a better name idea, let me know!" Language Orchestrator?
rorylawless 1y ago
Very unfortunate name collision with rv for R (https://github.com/A2-ai/rv https://github.com/A2-ai/rv).
- jxf 1y ago
  Is it really a name collision when they're effectively completely different namespaces? For example, no one thinks Rust's `cargo` might be the same thing as Ruby's obscure `cargo` library.
  - pxc 1y ago
    It's not a library. It's an executable that needs to be on the PATH to use it. And the executable has the exact same name.
    - jxf 1y ago
      So does the example I provided.
    - woodruffw 1y ago
      At this point, I think the namespace for 2-3 character CLI binaries has probably been clobbered several times over.
      - pxc 1y ago
        My lazy heuristic is to use nix-locate to search through the 100k packages in Nixpkgs, e.g.: > nix-locate -r 'bin/uv' Not perfect, but sort of useful for choosing names for executables for internal corporate projects, little wrapper scripts, etc. It's definitely still possible to find reasonable names! But I've never done the analysis of such short names yet :D
  - fuckaj 1y ago
    You might use R and Ruby. Wouldn't be unheard of. Alias ftw.
wferrell 1y ago
Nice André!
jacobsenscott 1y ago
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.
- pxc 1y ago
  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.
jrochkind1 1y ago
> 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.
- regularfry 1y ago
  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...
gurgeous 1y ago
I am so excited about this!! Ruby tooling is already pretty good, but we can do better. I will try to contribute. Now we just need types
- bingo-bongo 1y ago
  Take a look at Crystal for types: https://crystal-lang.org/ https://crystal-lang.org/
  - dcchambers 1y ago
    Crystal is cool but the only thing it shares in common with Ruby is a similar syntax. If you actually want types in Ruby, you should check out Sorbet: https://sorbet.org/ https://sorbet.org/
- dismalaf 1y ago
  Please no types... They're worse than pointless for a dynamically typed language.
  - bmacho 1y ago
    All dynamically typed Ruby competitors like Python, Javascript (via Typscript), PHP, Elixir have embraced Gradual Typing/Type Inference. You use typed variables/typed function signatures when it's convenient, they give you some compile-time contracts, easy documentation and probably even speed. Otherwise they don't exist. I don't do Ruby, but Gradual Types/Type Inference is a no-brainer for dynamic languages, practically no drawback, only benefits. (And popular statically typed languages such as C/C++, Java, Rust support Type Inference, or are going there too.)
    - dismalaf 1y ago
      Cool. People who want gradual typing can use those and leave Ruby alone. > I don't do Ruby So why have an opinion? Languages I use: Ruby, C++, Odin, R. I'm not about to to around telling Rust, Python or Typescript people they're doing their languages wrong, even if there's things I hate about those languages. I just don't use them.
dismalaf 1y ago
Has anyone ever actually had anything break from a Ruby version update? I know Matz basically never does breaking changes, last I remember is the 1.8.7 -> 1.9.2 update... I've only ever just straight up downloaded the source and installed it myself, never had any issues with Ruby updates...
- chao- 1y ago
  Depends what you mean by "break". There have been backwards-incompatible changes, but as you say, very few since the 1.8.7 to 1.9.X jump. I can think of one meaningful breaking change going from 2.7 to 3.0, where the longtime behavior of creating an implicit "options hash" as the last argument to a method was finally removed. It was gradual though. First we got keyword arguments. Then keyword arguments got faster. Then there were two versions of warnings about the removal of the old, implicit options hash. Thus if you really wanted to kick the can down the road, you had about 5 years where you could be on a "supported" Ruby version without having fixed your code. Plus the change required was relatively simple outside of a few edge cases. The best part was that most of the community was pretty good about upgrading gems across the years of warnings we had for this. Hats off to the maintainers and contributors for that!
- oezi 1y ago
  They moved quite some things out of the standard library so you need require/gems for some things which used to be batteries included. Also small changes like File.exists? being deprecated and then removed.
  - dismalaf 1y ago
    Yeah, and for some of these changes they gave you warnings for like a year straight in preparation.
anon6362 1y ago
No need because there's chruby and/or asdf that do it elegantly. Looks like NIH reventing rvm.
- steveklabnik 1y ago
  One of the team members is the creator of rbenv. It was litearlly invented here!
hotk 1y ago
uv has been the greatest development in the python ecosystem in the last decade. super excited about rv! PLEASE, enable sponsorship on github.com or elsewhere. I want to donate $$$!!!
vickodin 1y ago
The more tools the better. Thanks! As an idea: add advantages compared to rvm, rbenv, etc. Or a comparison table > Ruby Versions: Ruby 3.4.1 and up It turns out that this is only for the latest ruby versions :( But I will follow the development!
- notpushkin 1y ago
  > add advantages compared to rvm, rbenv, etc If I understand correctly, rvm/rbenv only install Ruby versions, and you use bundler to install dependencies. rv seems to manage everything (like uv in Python) – Ruby versions and dependencies, and adds things on top of that (like `rv tool` for global tools installation).
oblio 1y ago
He he. If this article isn't proof that people don't really want "do just one thing and do it well" (besides the million flags of ls and find), nothing is :-)
oezi 1y ago
As a long-time Rubyist and recent Python dabbler (due to pytorch) this is exciting! Uv and uvx certainly are great improvements in the Python ecosystem, but still have some quirks that I wonder how they will handle with rv: - By default uv is creating isolated environments in the project directory and will download all dependencies over the network. For small stuff this isn't too bad, but re-downloading 700mb pytorch each time you clone a repo gets annoying very fast. Of course there are trade-offs with running updates less frequently (and uv has flags such as --offline and --refresh to avoid or force online access) but more sensible default behavior would be nice so that uv (and rv) keep you on the happy path during developing. Maybe updates could be run in the background by default. - Also because the environments aren't shared in any way, each project directory consume a lot of disk space (10x checkouts = 10x pytorch on disk). More sensible caching across environments would be nice (links?). - Using uv to turn Python files into standalone/self-contained scripts is really great (https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/) and I hope rv can mirror this capability well. Because the lock file isn't included in the script header it requires some configuration options to make runs repeatable (e.g. https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...). - I am wondering if rv will support version operators such as rv install "~> 3.4.4" to get ruby ">= 3.4.4, < 3.5.0", which I think would help ensure everyone is running Ruby versions with security patches applied. - uv includes the pip sub-command (similar to using gem install rather than bundle add) but because the environments are isolated this feels rather weird and I haven't really understood in which cases you should not just use "uv add" to update your project dependencies. - Uv tries hard to support migration from legacy Python projects which don't have a pyproject.toml, but the Python eco-system is too fragmented for this to always work. I hope rv can avoid adding new config files, but really stick to the existing Gemfile approach. - If a Python package includes a script with a different name than the package then the syntax is a bit annoying ('uvx --from package script' but not 'uvx script --from package' because this would get passed to the script). Uv already uses square brackets for optional project dependencies (e.g. 'uvx --from huggingface_hub[cli] hf') but since Ruby doesn't have these, maybe this would be an option for rv.
- guipsp 1y ago
  Hard links are already used, when available. Are you on windows?
lutzh 1y ago
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? I put my hope in mise-en-place - https://mise.jdx.dev https://mise.jdx.dev What do people think? One tool per language, or one to rule them all?
- tracker1 1y ago
  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.
- cjk 1y ago
  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.
  - paffdragon 1y ago
    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.
ufmace 1y ago
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. [0] https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
- pxc 1y ago
  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!
- byroot 1y ago
  Same. Python’s virtual env always seemed to me like a weirdly complicated workaround for the limitations of the Python package managers. 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.
  - KingOfCoders 1y ago
    I only from time to time want to use some Python, but virtual env is always too complicated to me to get into after some months.
hexo 1y ago
and now ruby community is being shoveled with rust
- steveklabnik 1y ago
  The first production use of Rust was a Ruby extension.
  - zanellato19 1y ago
    Really? What was that? That's awesome
    - steveklabnik 1y ago
      Skylight, from Tilde.
andriamanitra 1y ago
I go between different languages a lot so having a command line interface that is consistent with the one I use in Python (uv) would definitely be appreciated. I mostly use Ruby for single-file scripts with no dependencies, which means I don't do projects often enough to remember how to use bundle/gem/rvm/whatever. It seems to me like `rv` is not quite ready to fully replace them just yet but I'm excited to see where the project goes. I'm also excited about `rv tool` because I've been having to re-install rubocop and ruby-lsp gems every time the minor version of the system Ruby is updated. It's just a few commands every year (and I'm sure it's a skill issue) but having things "just work" with a single `rvx rubocop` command will be sweet.
regularfry 1y ago
Oi! https://github.com/regularfry/rv https://github.com/regularfry/rv (Kidding! Looks interesting.)
chucke 1y ago
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.
KingOfCoders 1y ago
not being dismissive of the effort or other tools and languages, not trying to convince anyone After decades of Java (ant/maven), then Scala (sbt), then JS (npm), then TS, switching to Go (Make) some years ago made many problems go away. The tooling (test, ...) inside the main tool (Rust still a little better I think), now tools/versions inside go.mod, the result of my work being a binary I can run with systemd, embedding files into the binary, all of that removed a lot of dep management issues, building issues, bundling issues, and the need for e.g. Docker for many use cases (which I feel many people only use to package .jar files or gems into something that can run in production). Seems rv wants the same, "Our end goal is a completely new kind of management tool, [...] Not a version manager, or a dependency manager, but both of those things and more. I’m currently calling this category a “language manager”"

333 points by steveklabnik 1y ago

Naturally written in Rust. I could start taking bets every time I now see a "new kind of tool" for XYZ. I am firmly in the camp tools for specific ecosystems should be written on the language of said ecosystem. If one is hindered by the language, maybe that isn't the right ecosystem, or therein lies the opportunity for language toolchain improvements.

tracker1 1y ago
Or... rust lends itself to fast executing CLI tooling... and that no language/hammer is best when you need a screwdriver.
- pjmlp 1y ago
  Plenty of languages do offer AOT toolchains, and CLIs have been part of computing since we have teletypes.
  - tracker1 1y ago
    In this case, we're talking about ruby... does ruby output AOT, portable executables in the box?
    - pjmlp 1y ago
      If you're willing to pay for it. http://www.rubymotion.com/ http://www.rubymotion.com/ Plus since when is AOT compilation required for CLI tools? Half of UNIX userspace would be gone.
      - tracker1 1y ago
        When you're talking about portable tooling in order to install other stuff it sure helps.
        pjmlp 1y ago
        Apparently it was never a problem in the UNIX lifetime.
        tracker1 1y ago
        Yep, nobody ever, not once had trouble bootstrapping something like GCC in a new environment at all, ever.

dcchambers 1y ago

On the one hand, the ruby development ecosystem is in a much better state than Python was before uv. Bundler is way better than anything Python had before uv. On the other hand, a uv-like all-in-one for Ruby is really interesting/tempting.

1a527dd5 1y ago

Can we not have this new trend of two letter projects? It makes it super hard to Google for in the future, give it an actual name please. I don't know if the trend started with uv, but please for future engineers trying to debug/learn make it Google-able.

msie 1y ago

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.

jacobsenscott 1y ago
Just using `bundle exec` should handle that - that's what bundler is for.
- msie 1y ago
  Yep, didn't work.
  - byroot 1y ago
    Yes, this is due to the effort to extract stdlib code into gems https://stdgems.org/ https://stdgems.org/ In your case, StringIO use to just be stdlib code so bundler (or rubygems) uses it. Later on it became a gem, so by requiring it before reading the Gemfile, bundler run into this problem of already having loaded the wrong version. Everytime this happens the bundler team has to modify bundler, and as a user the fix is to upgrade bundler. You can see they had to vendor a lot of code from default gems to avoid this problem: https://github.com/rubygems/rubygems/tree/c230844f2eab31478f718a80d5980a70aa6a897d/bundler/lib/bundler/vendor https://github.com/rubygems/rubygems/tree/c230844f2eab31478f...

bradly 1y ago

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.

jweir 1y ago

fast installs will be great. compiling ruby is the only slow part left in our provisioning process.

inopinatus 1y ago
to this end I have been deploying with the fullstaq-ruby builds for some years now.
- jweir 1y ago
  we have investigate that, but it requires sudo access which is not allowed but the running user.
  - inopinatus 1y ago
    You may find the fakeroot utility goes a long way to help. But never forget that binary packages are merely archives, or sometimes, archives-of-archives (as in Debian); we can unroll them anywhere.
gtirloni 1y ago
why are you compiling ruby during provisioning?

jemmyw 1y ago

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.

evolve2k 1y ago
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.
- jemmyw 1y ago
  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.
rictic 1y ago
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.

sleepy_keita 1y ago

I find it interesting how Rust is gaining momentum in tooling like uv and now rv.

deleted 1y ago
[deleted]
inopinatus 1y ago
Rust is the new C. Go had a shot but went in an applications direction. I predict that very soon, perhaps even inside of three decades, Rust will become the dominant, first-choice systems programming language.
- hu3 1y ago
  Go can do just as well in tooling. Microsoft chose Go for tsc rewrite. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-... And then there's esbuild, also in Go, which revolutionized web bundling speed https://esbuild.github.io https://esbuild.github.io
  - inopinatus 1y ago
    That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point. Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.
  - tough 1y ago
    I love both Go and Rust but Go is GC no? Where rust shines is on its safety at compile time and lifetime/borrow/memory model imho both are awesome tools!

natt941 1y ago

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!

DavidCanHelp 1y ago

"Not a version manager, or a dependency manager, but both of those things and more. I’m currently calling this category a “language manager”, but if you have a better name idea, let me know!" Language Orchestrator?

rorylawless 1y ago

Very unfortunate name collision with rv for R (https://github.com/A2-ai/rv https://github.com/A2-ai/rv).

jxf 1y ago
Is it really a name collision when they're effectively completely different namespaces? For example, no one thinks Rust's `cargo` might be the same thing as Ruby's obscure `cargo` library.
- pxc 1y ago
  It's not a library. It's an executable that needs to be on the PATH to use it. And the executable has the exact same name.
  - jxf 1y ago
    So does the example I provided.
  - woodruffw 1y ago
    At this point, I think the namespace for 2-3 character CLI binaries has probably been clobbered several times over.
    - pxc 1y ago
      My lazy heuristic is to use nix-locate to search through the 100k packages in Nixpkgs, e.g.: > nix-locate -r 'bin/uv' Not perfect, but sort of useful for choosing names for executables for internal corporate projects, little wrapper scripts, etc. It's definitely still possible to find reasonable names! But I've never done the analysis of such short names yet :D
- fuckaj 1y ago
  You might use R and Ruby. Wouldn't be unheard of. Alias ftw.

wferrell 1y ago

Nice André!

jacobsenscott 1y ago

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.

pxc 1y ago
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.

jrochkind1 1y ago

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

regularfry 1y ago
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...

gurgeous 1y ago

I am so excited about this!! Ruby tooling is already pretty good, but we can do better. I will try to contribute. Now we just need types

bingo-bongo 1y ago
Take a look at Crystal for types: https://crystal-lang.org/ https://crystal-lang.org/
- dcchambers 1y ago
  Crystal is cool but the only thing it shares in common with Ruby is a similar syntax. If you actually want types in Ruby, you should check out Sorbet: https://sorbet.org/ https://sorbet.org/
dismalaf 1y ago
Please no types... They're worse than pointless for a dynamically typed language.
- bmacho 1y ago
  All dynamically typed Ruby competitors like Python, Javascript (via Typscript), PHP, Elixir have embraced Gradual Typing/Type Inference. You use typed variables/typed function signatures when it's convenient, they give you some compile-time contracts, easy documentation and probably even speed. Otherwise they don't exist. I don't do Ruby, but Gradual Types/Type Inference is a no-brainer for dynamic languages, practically no drawback, only benefits. (And popular statically typed languages such as C/C++, Java, Rust support Type Inference, or are going there too.)
  - dismalaf 1y ago
    Cool. People who want gradual typing can use those and leave Ruby alone. > I don't do Ruby So why have an opinion? Languages I use: Ruby, C++, Odin, R. I'm not about to to around telling Rust, Python or Typescript people they're doing their languages wrong, even if there's things I hate about those languages. I just don't use them.

dismalaf 1y ago

Has anyone ever actually had anything break from a Ruby version update? I know Matz basically never does breaking changes, last I remember is the 1.8.7 -> 1.9.2 update... I've only ever just straight up downloaded the source and installed it myself, never had any issues with Ruby updates...

chao- 1y ago
Depends what you mean by "break". There have been backwards-incompatible changes, but as you say, very few since the 1.8.7 to 1.9.X jump. I can think of one meaningful breaking change going from 2.7 to 3.0, where the longtime behavior of creating an implicit "options hash" as the last argument to a method was finally removed. It was gradual though. First we got keyword arguments. Then keyword arguments got faster. Then there were two versions of warnings about the removal of the old, implicit options hash. Thus if you really wanted to kick the can down the road, you had about 5 years where you could be on a "supported" Ruby version without having fixed your code. Plus the change required was relatively simple outside of a few edge cases. The best part was that most of the community was pretty good about upgrading gems across the years of warnings we had for this. Hats off to the maintainers and contributors for that!
oezi 1y ago
They moved quite some things out of the standard library so you need require/gems for some things which used to be batteries included. Also small changes like File.exists? being deprecated and then removed.
- dismalaf 1y ago
  Yeah, and for some of these changes they gave you warnings for like a year straight in preparation.

anon6362 1y ago

No need because there's chruby and/or asdf that do it elegantly. Looks like NIH reventing rvm.

steveklabnik 1y ago
One of the team members is the creator of rbenv. It was litearlly invented here!

hotk 1y ago

uv has been the greatest development in the python ecosystem in the last decade. super excited about rv! PLEASE, enable sponsorship on github.com or elsewhere. I want to donate $$$!!!

vickodin 1y ago

The more tools the better. Thanks! As an idea: add advantages compared to rvm, rbenv, etc. Or a comparison table > Ruby Versions: Ruby 3.4.1 and up It turns out that this is only for the latest ruby versions :( But I will follow the development!

notpushkin 1y ago
> add advantages compared to rvm, rbenv, etc If I understand correctly, rvm/rbenv only install Ruby versions, and you use bundler to install dependencies. rv seems to manage everything (like uv in Python) – Ruby versions and dependencies, and adds things on top of that (like `rv tool` for global tools installation).

oblio 1y ago

He he. If this article isn't proof that people don't really want "do just one thing and do it well" (besides the million flags of ls and find), nothing is :-)

oezi 1y ago

As a long-time Rubyist and recent Python dabbler (due to pytorch) this is exciting! Uv and uvx certainly are great improvements in the Python ecosystem, but still have some quirks that I wonder how they will handle with rv: - By default uv is creating isolated environments in the project directory and will download all dependencies over the network. For small stuff this isn't too bad, but re-downloading 700mb pytorch each time you clone a repo gets annoying very fast. Of course there are trade-offs with running updates less frequently (and uv has flags such as --offline and --refresh to avoid or force online access) but more sensible default behavior would be nice so that uv (and rv) keep you on the happy path during developing. Maybe updates could be run in the background by default. - Also because the environments aren't shared in any way, each project directory consume a lot of disk space (10x checkouts = 10x pytorch on disk). More sensible caching across environments would be nice (links?). - Using uv to turn Python files into standalone/self-contained scripts is really great (https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/) and I hope rv can mirror this capability well. Because the lock file isn't included in the script header it requires some configuration options to make runs repeatable (e.g. https://docs.astral.sh/uv/guides/scripts/#improving-reproducibility https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...). - I am wondering if rv will support version operators such as rv install "~> 3.4.4" to get ruby ">= 3.4.4, < 3.5.0", which I think would help ensure everyone is running Ruby versions with security patches applied. - uv includes the pip sub-command (similar to using gem install rather than bundle add) but because the environments are isolated this feels rather weird and I haven't really understood in which cases you should not just use "uv add" to update your project dependencies. - Uv tries hard to support migration from legacy Python projects which don't have a pyproject.toml, but the Python eco-system is too fragmented for this to always work. I hope rv can avoid adding new config files, but really stick to the existing Gemfile approach. - If a Python package includes a script with a different name than the package then the syntax is a bit annoying ('uvx --from package script' but not 'uvx script --from package' because this would get passed to the script). Uv already uses square brackets for optional project dependencies (e.g. 'uvx --from huggingface_hub[cli] hf') but since Ruby doesn't have these, maybe this would be an option for rv.

guipsp 1y ago
Hard links are already used, when available. Are you on windows?

lutzh 1y ago

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? I put my hope in mise-en-place - https://mise.jdx.dev https://mise.jdx.dev What do people think? One tool per language, or one to rule them all?

tracker1 1y ago
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.
cjk 1y ago
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.
- paffdragon 1y ago
  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.

ufmace 1y ago

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. [0] https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...

pxc 1y ago
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!
byroot 1y ago
Same. Python’s virtual env always seemed to me like a weirdly complicated workaround for the limitations of the Python package managers. 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.
- KingOfCoders 1y ago
  I only from time to time want to use some Python, but virtual env is always too complicated to me to get into after some months.

hexo 1y ago

and now ruby community is being shoveled with rust

steveklabnik 1y ago
The first production use of Rust was a Ruby extension.
- zanellato19 1y ago
  Really? What was that? That's awesome
  - steveklabnik 1y ago
    Skylight, from Tilde.

andriamanitra 1y ago

I go between different languages a lot so having a command line interface that is consistent with the one I use in Python (uv) would definitely be appreciated. I mostly use Ruby for single-file scripts with no dependencies, which means I don't do projects often enough to remember how to use bundle/gem/rvm/whatever. It seems to me like `rv` is not quite ready to fully replace them just yet but I'm excited to see where the project goes. I'm also excited about `rv tool` because I've been having to re-install rubocop and ruby-lsp gems every time the minor version of the system Ruby is updated. It's just a few commands every year (and I'm sure it's a skill issue) but having things "just work" with a single `rvx rubocop` command will be sweet.

regularfry 1y ago

Oi! https://github.com/regularfry/rv https://github.com/regularfry/rv (Kidding! Looks interesting.)

chucke 1y ago

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.

KingOfCoders 1y ago

not being dismissive of the effort or other tools and languages, not trying to convince anyone After decades of Java (ant/maven), then Scala (sbt), then JS (npm), then TS, switching to Go (Make) some years ago made many problems go away. The tooling (test, ...) inside the main tool (Rust still a little better I think), now tools/versions inside go.mod, the result of my work being a binary I can run with systemd, embedding files into the binary, all of that removed a lot of dep management issues, building issues, bundling issues, and the need for e.g. Docker for many use cases (which I feel many people only use to package .jar files or gems into something that can run in production). Seems rv wants the same, "Our end goal is a completely new kind of management tool, [...] Not a version manager, or a dependency manager, but both of those things and more. I’m currently calling this category a “language manager”"