Comment by AlphaSite
19 hours ago
Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.
19 hours ago
Speed would be nice, but more than that I want it to also manage Ruby installs. I’m infuriated at the mess of Rubys and version managers.
Mise is the answer to this. I no longer use chruby/rbenv/rvm. And it manages multiple languages, project-local environment, etc.
Well. GoboLinux solved that already. Back in 2005.
I never understood the real need for chruby rvm etc... - I manage everything, all programs, in a versioned AppDir manner. (Note: I am not using GoboLinux; I use a modified variant. GoboLinux gave the correct idea though.)
Context for anyone unfamiliar with GoboLinux:
> each program in a GoboLinux system has its own subdirectory tree, where all of its files (including settings specific for that program) may be found. Thus, a program "Foo" has all of its specific files and libraries in /Programs/Foo, under the corresponding version of this program at hand. For example, the commonly known GCC compiler suite version 8.1.0, would reside under the directory /Programs/GCC/8.1.0
https://en.wikipedia.org/wiki/GoboLinux
And the bank where I worked in mid 1990s had the same each program in its own versioned directory.
That takes me back. I haven't used GoboLinux since maybe 2007ish but I used to maintain several packages for it.
It's not really that easy being really different in the Linux packaging world.
Or GNU Stow.
to me the languages themselves should handle it
mise is pretty nice, though I don't use it for python, Python is handled by uv with poethepoet as the task runner.
Can you help me understand what the value or use case of poethepoet is?
1 reply →
FWIW mise has a task runner built-in too.
How does it compare to asdf?
https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
> mise can be used as a drop-in replacement for asdf. It supports the same .tool-versions files that you may have used with asdf and can use asdf plugins through the asdf backend.
> It will not, however, reuse existing asdf directories (so you'll need to either reinstall them or move them), and 100% compatibility is not a design goal. That said, if you're coming from asdf-bash (0.15 and below), mise actually has fewer breaking changes than asdf-go (0.16 and above) despite 100% compatibility not being a design goal of mise.
> Casual users coming from asdf have generally found mise to just be a faster, easier to use asdf.
I manage all my programs via ruby in a manner similar to GoboLinux, e. g. versioned AppDirs. So I don't need uv or anything else for this - not that I have anything against uv, it is just not something I need myself. But I agree with you in that there are multiple objectives or goals to be had here; you mention one, Aaron mentioned speed. I think there are many more (I mentioned documentation before too; people in ruby seem to think documentation is not important, or at the least really many think in that way - look at the documentation of rack, it is virtually not existing. I am not going to sift through low quality ruby code for hours to try to figure out what madness drove this or that author to write some horrible-to-read junk of code. A project without good documentation is worthless. Why do ruby developers not learn this lesson?).
I think all of ruby, including the ecosystem as well as how ruby is governed, needs to be considered. In particular with ruby constantly declining and losing user share. That is not good. That should change.
I'm always surprised to hear this, and I want to be clear that I'm not trying to be dismissive in my comment. However, I've not encountered issues while juggling dozens of Ruby projects since around 2011, despite seeing many people's complaints over the years. Ten years ago I was using rvm, and I saw people sharing their issues with it, and listing reasons why rbenv and chruby are better. So I tried those, and my resulting workflow felt basically the same once I got used to the differences.
At this point I've used rbenv, rvm, asdf, mise, and one other whose name isn't coming to mind. Not to mention docker containers, with or without any of those tools.
I don't mean to project any particular complaint onto you, and I'm curious what part of it is infuriating? Each of the version managers I've used has functioned as advertised, and I'm able to get back to work pretty smoothly.
My experience with the ruby ecosystem has been that if you get everything set up correctly all of the environment management tools have worked wonderfully. When you don't have everything set up correctly, they break in ways that is hard to understand for someone not intimately familiar with the ecosystem. It's something that's not at all a problem for someone using ruby as their primary language, and a major source of pain for dabblers and people who just want to run something written in ruby.
That's a fair point. That's why I'm interested to know what is at the core of AlphaSite's complaint.
One challenge, as I see it, is that there are three kinds of Ruby projects that need to take different approaches to the matter, in increasing level of complexity:
(1) Developing a longer-lived, deployed or distributed project. Here you should definitely use both the Gemfile Ruby version and a .ruby-version file. You're normally only targeting one version at a time, but contributors and/or users are very unlikely to somehow accidentally end up using the wrong Ruby version without getting a very obvious notification that they are using the wrong Ruby version. That's annoying to encounter, but not difficult to solve once you know that the concept of a "version manager" exists.
(2) Hacking on your own small project or just banging out a script. You just want to run some Ruby version and get to it. You probably should default to the latest, unless there's some dependency requiring a lower version, and you might not know that until after you've gotten started. The inverse issue might also occur, e.g. you installed Ruby 3.1 a few years ago, you start hacking, and now you want to pull in a gem version that requires Ruby 3.4. You can manage this by putting the Ruby version in your Gemfile, or using a .ruby-version file, or both, but if you're relatively green and just diving in, this might not be on your radar.
(3) Developing a gem. You probably want to test/validate your gem across multiple Ruby versions, and possibly even different versions of your dependencies. You obviously don't want to lock yourself into a single Ruby version, and use of a .ruby-version file is inappropriate. There is tooling to do this, but it takes some learning to be able to utilize.
My belief is that it is worth it for install documentation for category (1) to be a little more explicit about how to get up and running. For category (2), I don't know what the right answer is, but I understand the potential pain points.
What I was most curious about is whether AlphaSite's complaint was with a specific version manager, or the fact that multiple options for version managers exist, or even the need for version managers at all?
Maybe https://github.com/spinel-coop/rv will be the answer when it's ready
what exactly is your issue? I've been using rvm for a decade(?) without any major pain. Cross-language tools such as mise or asdf also seem to work ok.
I can relate to the "I wish we didn't need a second tool", but it doesn't seem like much of a mess.
Of all the languages I've touched, managing multiple ruby versions has been one of the easiest.
I've been using pyenv for a decade before uv and it wasn't a "major pain" either. But compared to uv it was infinitely more complex, because uv manages python versions seamlessly.
If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.
And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.
What do you use to manage other languages? Asking because asdf is basically a multi language version of a ruby version manager rbenv