🐋 building the devcontainer is slow

[DerekNonGeneric]

Building the devcontainer is slow because rbenv install takes forever as it is building ruby from source. We can circumvent this by using rvm. Ideally, we would have an rvm.fish just like we have nvm.fish, but the former does not yet exist. The task at hand is to write one of those in pure fish 3.0, install it using fisher, and install the pre-compiled binary for this platform using it.

[DerekNonGeneric]

I do not like that so much of the logic involved in setting up/building the devcontainer takes place at the expense of contributor time. I would like to be able to have all of that take place elsewhere and provide users of this project something similar to https://github.com/andreiborisov/docker-fish including the whole dev environment potentially as additional "layers".

[DerekNonGeneric]

The setup-ruby GitHub action is installing pre-built binaries from the ruby-builder project's latest releases.

[DerekNonGeneric]

propose to create a new rbenv plugin called ruby-builder for installing pre-built binaries from the ruby-builder project's latest releases.

this is the only alternative i see because ruby-build doesn't let you install pre-built binaries.

[DerekNonGeneric]

[…] to investigate differences between ruby-builder and how we build Ruby from our side.
The main difference is that you build with shared libs support that means that binaries are bound to location where they were built and can’t be run from different location.
— ruby/setup-ruby#98 (comment)

Preliminary findings show that they are still built with shared libs support:

/home/vscode/.rbenv/versions/3.2.2/bin/ruby: error while loading shared libraries: libruby.so.3.2: cannot open shared object file: No such file or directory

Binaries are bound to location where they were built and can’t be run from different location.