Ruby Feature: Which ruby version manager would you prefer?

[samruddhikhandale]

Hello! 👋

We are looking forward to get some feedback for refactoring the Ruby Feature.

Which Ruby version manager would you like the Feature to install by default? You can use the respective emojis for voting your preference!

1. None - 😕
2. rbenv - 🎉
3. rvm - 🚀
4. Any other (feel free to drop a comment)

For the ruby Feature, we have heard issues with conflicting ruby managers (rbenv and rvm) which can be problematic for complex projects. We have a community member who is willing to contribute a PR with the necessary changes ✨ See #603 (comment) ❤

(Draft) Proposal

• Create a new Feature option which will define the ruby version manager to be used for installing ruby
  • Let’s say we call it rubyVersionManager
  • It will be string with enum: ["none", "rbenv", "rvm"])
  • Default value: "TBD: Poll result"
• Based on the value provided by rubyVersionManager, the Feature will use that version manager to install ruby
• In case of none, we will first attempt to install it with apt.
  • If it fails, then install from source.

Looking forward to everybody's feedback, thank you!

[nevans]

In the case of installing with apt, do we just accept whatever version comes from the OS? Or do we require that it matches the version that was specified for the container? Although I do like to use Debian/Ubuntu packages when I can, they will be constrained as to which version can be installed. For consistency, I think it's probably better to always "install from source" in the normal "none" case and simply ignore the OS distribution's packages (and maybe add a fourth "apt" option?).

[ThomasOwens]

@nevans

I was trying to not scope-creep this too much, but I think I see what you're getting at.

From what I can tell, the default none case does rely on whatever comes from the container. That isn't the best solution. It looks like Debian comes with Ruby and the common-utils feature runs an upgrade of all OS packages. If I'm understanding the scripts correctly, none always gets you the latest Ruby release (in the Debian repos, anyway). Not necessarily what people want. Plus, if Debian stopped distributing Ruby for some reason, we'd be in a tough spot.

I believe the solution is this:

1. Create a new Feature option rubyVersionManager to define the Ruby version manager. It will be a string with enum: ["none", "rbenv", "rvm"]. The default value will be the poll results here.
2. Create a new Feature option rubyVersion to define the version of Ruby to install. It will be a string with some proposals for supported Ruby versions. This should be freeform, though, and parsed out to download any version of Ruby.
3. Based on the values of rubyVersionManager and rubyVersion, install the specified Ruby version. Install from source for none or using the version manager otherwise. When installing from source, set the path variables properly.

Would need to deal with the Ruby version from source. The URL for the source tarball for Ruby X.Y.Z would be https://cache.ruby-lang.org/pub/ruby/X.Y/ruby-X.Y.Z.tar.gz or https://github.com/ruby/ruby/archive/refs/tags/vX_Y_Z.tar.gz. That's not so bad. The preview versions, on the other hand, are of the format https://cache.ruby-lang.org/pub/ruby/X.Y/ruby-X.Y.Z-previewN.tar.gz or https://github.com/ruby/ruby/archive/refs/tags/v3_3_0_previewN.tar.gz. You need to not only know the major, minor, and patch version, but also the fact that it is a preview and which preview build it is. I'd have to think this through some more. I'd also need to understand how version managers specify preview builds. Although perhaps we don't need to worry about preview versions at all - anyone using one of them in a dev container can create custom onCreate or postCreate scripts to handle this specific case.

This does bring up an interesting question, though. Perhaps I was wrong in that no version manager should be installed. If you want true isolation between whatever Ruby comes with the OS and your app's Ruby version, the best way to do that is a version manager. I should revisit good practices for containerization of Ruby applications - perhaps it is insufficient to be containerized and use a system Ruby.

[samruddhikhandale]

In the case of installing with apt, do we require that it matches the version that was specified for the container?

Yes, this was the plan ^

As installing from apt is faster than installing from source. We thought it made sense to try adding ruby with apt.

For consistency, I think it's probably better to always "install from source" in the normal "none" case and simply ignore the OS distribution's packages (and maybe add a fourth "apt" option?).
Although I do like to use Debian/Ubuntu packages when I can, they will be constrained as to which version can be installed.

We could also update the version option to accept os-provided, and it installs whichever version is available in apt feeds.

[samruddhikhandale]

Create a new Feature option rubyVersion to define the version of Ruby to install. It will be a string with some proposals for supported Ruby versions. This should be freeform, though, and parsed out to download any version of Ruby.

@nevans we already have version option, why not use that?

[samruddhikhandale]

Can we install ruby from the prebuilt binaries available in https://github.com/ruby/ruby-builder/releases/tag/toolcache ? This would make the Ruby Feature way faster to install. Also, we could still keep the install from source fall back if some version is not available in prebuilt binaries.

Update:

• In case of none, we will first attempt to install from https://github.com/ruby/ruby-builder/releases/tag/toolcache
  • If it fails, then install from source.

[ThomasOwens]

@samruddhikhandale

Thinking this through, I'm not sure using the OS-provided version will work. I need to test this specifically, but that version will get updated when the common-utils feature updates all the OS packages. If that is indeed the case, a devcontainer user has no control over the OS-provided Ruby version. Plus, if other OS-packages have a dependency or otherwise expect a more recent version of Ruby than what the application needs, other OS-packages could end up in a non-functional state.

I know I was one of the people who questioned even installing a Ruby version manager. And in very lightweight production Ruby container, that may make sense if the only thing the container is doing is running your application. However, in a development environment, you have other tools. And I'm not sure I'd want to be forcing the version of Ruby to something else, especially a much lower version than what is in the OS repositories.

I'm starting to lean toward requiring a Ruby version manager, even if it only points to the OS-installed Ruby version. It would still cause an issue if the OS ever stopped providing Ruby, but that could be a breaking change for a lot of people out there.

I can look at using ruby-builder's toolcache as a possibility. But the standard container is a Debian container. Not sure if the Ubuntu builds will work. Maybe worth a look, though.

Overall, it doesn't change the approach I'm taking. Just a few minor details to work out.

[nevans]

As installing from apt is faster than installing from source. We thought it made sense to try adding ruby with apt.

It does make sense! ...except that it probably won't match the requested version. 😉

We could also update the version option to accept os-provided, and it installs whichever version is available in apt feeds.

That option makes sense to me. Are there other devcontainer features that go this route? If so, then we can follow their lead. Is os-provided a version name that is used by other devcontainer features? I think I've seen system used more commonly by various version managers, but consistency with other devcontainer features should take priority, IMO.

Thinking this through, I'm not sure using the OS-provided version will work

Honestly, I think that skipping the os-provided version is the simplest approach, at least for the first pass. Maybe iterate to allow that as an option in the future, after the most important case is handled: ensuring the user-specified version is installed.

I'm starting to lean toward requiring a Ruby version manager

Similarly, while it might be nice to provide a simple "no version manager" option, that doesn't need to be in the first updated release. We can iterate towards that. But it's not an option today, so it's not like the feature would be losing any functionality if it's left out of a first PR.

When installing from source, set the path variables properly.

Note that installing from source should be fine without setting any ENV variables, so long as ruby is installed to /usr/local/bin (which is the default for installing from source). In my opinion, it's preferred: rubygems uses smart dynamic defaults for GEM_HOME and GEM_PATH but only when they aren't set. Setting them to empty strings will prevent these defaults from being used, and docker makes it difficult to unset environment variables. Similarly, I think that rbenv should only need its own binaries and shims to be on the PATH. Setting any other env vars will override everything that rbenv does in its shims.

rvm might need GEM_HOME and GEM_PATH (I'm not sure). But you may want to keep them as-is even if it doesn't need them, simply for backward compatibility with the current feature.

The biggest problem with setting these vars is that the dynamic defaults will automatically adjust the directories based on binary compatibility with your current ruby version. When they env vars are set statically, you can wind up with compiled extensions that are incompatible with your currently installed ruby version... which kind of defeats the purpose of a version manager. 😉 ENV variables are great for overrides, but lousy for dynamic defaults.

I can look at using ruby-builder's toolcache as a possibility. But the standard container is a Debian container. Not sure if the Ubuntu builds will work. Maybe worth a look, though.

Even if you were able to get it working with both Ubuntu and Debian, I'd still want to open an issue in that repo to make sure they're okay taking on a new dependency. It may be that they don't want to promise ongoing compatibility and stability for anything other than https://github.com/ruby/setup-ruby.

---

If you do create a default "install" script, I recommend that 1) we install to /usr/local and 2) we should lean heavily on one of the other existing tools. Some options:

• copy and adapt the script from the official Docker Hub ruby Dockerfile
• Install into /usr/local using one of the version managers' build/install tools without the rest of the version manager. If no version manager is being installed, the build tool could be deleted/uninstalled after it's used.
  • https://github.com/rbenv/ruby-build (without rbenv)
  • https://github.com/postmodern/ruby-install (without chruby)
  • It looks like rvm has a mrvm feature, which provides rvm's installation feature without any of rvm's other features.

And if the standard defaults don't work for some reason, rather than set the standard ENV vars, we should consider doing what the linux distros do, and add our own 'operating_system.rb' file to rubygems. See, for example:

• https://github.com/rubygems/rubygems/blob/8c0c3b6a74da2ae6dedbad7aaacdd4c0c1201b16/lib/rubygems/defaults.rb#L274
• https://github.com/rubygems/rubygems/blob/8c0c3b6a74da2ae6dedbad7aaacdd4c0c1201b16/lib/rubygems/config_file.rb#L55
• https://github.com/rubygems/rubygems/blob/8c0c3b6a74da2ae6dedbad7aaacdd4c0c1201b16/lib/rubygems.rb#L1314-L1329
• Debian and Ubuntu: https://salsa.debian.org/ruby-team/rubygems-integration/-/blob/master/lib/rubygems/defaults/operating_system.rb
• Fedora: https://src.fedoraproject.org/rpms/rubygems/raw/rawhide/f/operating_system.rb

[samruddhikhandale]

Thank you @ThomasOwens @nevans for your amazing thoughts, appreciate it! ✨

Is os-provided a version name that is used by other devcontainer features?

Yes, Python and Git Feature currently supports ie. See https://github.com/search?q=repo%3Adevcontainers%2Ffeatures%20os-provided&type=code

It does make sense! ...except that it probably won't match the requested version. 😉
Honestly, I think that skipping the os-provided version is the simplest approach, at least for the first pass.

Apologies for not writing a detailed proposal, I was proposing to use apt only if the requested version matches with the one available in the feeds. However, if not, install from source.

If we could support os-provided as a value for version, then this is way better approach. The reason to have an option to install from apt is simply because that's faster. Installing from source takes quite a lot of time compared to installing from apt, and we could soon hear complaints about the Feature taking too long 😅 So this is kind of like a precaution and a faster alternative.

I know I was one of the people who questioned even installing a Ruby version manager

Similarly, while it might be nice to provide a simple "no version manager" option, that doesn't need to be in the first updated release. We can iterate towards that. But it's not an option today, so it's not like the feature would be losing any functionality if it's left out of a first PR.

I agree having some ruby version manager is definitely better than having none. Then we have that question of which version manager should be installed by default? Should it be rvm, rbenv or something else?

According to the current polls, it's one vote for rbenv and three votes for none 😅

We definitely want to refactor the Ruby Feature as per how the community prefers, but it doesn't seem like we have enough votes right now.

If folks prefer to not have any ruby version manager installed, and if it's possible to install the requested version of ruby from source or ruby prebuilt binaries, then having none as default makes sense. This will most likely be used by learner development scenarios who doesn't have a preference on version managers and simply want some working version of ruby for their hobby projects.

In case of more complex scenarios, folks would have their own preference of ruby version managers which they could simply install with rubyVersionManager option.

Talking about the Ruby image, depending upon how this discussion evolves, we could decide a plan for it.

But you may want to keep them as-is even if it doesn't need them, simply for backward compatibility with the current feature.

This refactoring PR would most likely be a major version bump of the Feature. Major version bumps don't necessarily guarantee that it supports back compat, hence, if this might cause any other (future) issues, then we could avoid adding it.

Even if you were able to get it working with both Ubuntu and Debian, I'd still want to open an issue in that repo to make sure they're okay taking on a new dependency. It may be that they don't want to promise ongoing compatibility and stability for anything other than https://github.com/ruby/setup-ruby.

That sounds like a great idea, @nevans feel free to loop me in if necessary

[ThomasOwens]

@nevans and @samruddhikhandale

I've opened a draft/work-in-progress PR to start to show my work iteratively.

At this point, there should be parity with the Node Feature. I used that as a model since Node is frequently used to satisfy a dependency in Rails so I have some familiarity with setting up a Node development environment. I also noticed that they were using NVM, which is the Node equivalent to RVM. Although I prefer rbenv (and nodenv), this is a good first step. The initial issue of having multiple version managers has been resolved, which was my number one concern. At this point, I think it's iteration until it's good enough to merge.

Would need to check and images that use this Feature just to make sure requesting the image will be fine. I know it's used in the Ruby and the Ruby on Rails and Postgres devcontainers, but I'm not sure how to test building those while pointing at my modified feature.

[samruddhikhandale]

// cc @eljog and @joshspicer for visibility.

[ThomasOwens]

@samruddhikhandale @eljog @joshspicer

I realize it's getting close to holiday time in the US and you're all US-based from your profiles, so not expecting a fast response, but I wanted to check in on how to get this to a ready-to-merge state.

I have two open questions:

• What is the minimum feature set to merge a PR? Right now, the current PR resolves the (most important) issue of installing multiple version managers and has parity with the Node Feature. This PR, in current state, would allow me to confidently use the devcontainer. There is discussion of other features - rbenv, choosing system ruby version. I'm not sure what the minimum state to be broadly useful or acceptable is.
• Is the test coverage good? I see that the actual Ruby images use a Ruby image as their base. That seems both unexpected and wrong to me, but perhaps the tests should reflect the current reality rather than the ideal state.

Once the minimum feature set is implemented with appropriate test coverage, I can flip the PR out of its draft state.