Prototype: Install from Binary

[technicalpickles]

This is work towards #42

I have only confirmed this on Ubuntu x86_64, with MRI releases. There will need to be some more work to make it more generalized, and supporting other systems. I built this off of my other PR #1760 thinking I would use that to build, and this to install. I can rebase if necessary.

Screen.Recording.2021-04-23.at.3.49.02.PM.mov

[technicalpickles]

There will need to be some more work to make it more generalized, and supporting other systems.

I was looking more closely at the RVM mirror, and seems that some of these have not been updated particularly recently (5 years). 10.12, vs Big Sur which is 11.2.

[mislav]

This is great. Thanks for working on this!

My expectation was that --movable was added to produce the binaries that are later downloaded with --binary. But looking at the diff, that's not the case, as this downloads RVM's own movable rubies. In the long term, where should we download the rubies from, and how do we verify their authenticity?

[hsbt]

I have no idea to support pre-build binary without ruby-build team. At least, I will not support and investigate them.

[technicalpickles]

But looking at the diff, that's not the case, as this downloads RVM's own movable rubies.

This is squarely in prototype territory. I didn't have a good place to toss those built iwth --movable at the time I was working on.

In the long term, where should we download the rubies from, and how do we verify their authenticity?

I was thinking about this. I could imagine having something similar to share/ruby-build/<version>:

install_binary "<digest>" "url"

Something I had been thinking about is, how much does this overlap with the existing ruby-build code? The main hooks are using an existing binary rather than building. But the fetch code? It'd be new code.

I could imagine more code being needed to download from GitHub Packages like I mentioned in #42 (comment) . I could also imagine having publish a built file. homebrew had a lot of tooling around both of those already (fetching and publishing), so it wasn't as big of a lift for that project.

As @hsbt said, this would need to be hosted somewhere and managed by someone. I think if we can have a way to let people add repositories of binaries w/ a preference to install them, that would still be a great step forward. It would also help validate the approach for a wider audience.

[mislav]

I could imagine more code being needed to download from GitHub Packages like I mentioned in #42 (comment) . I could also imagine having publish a built file. homebrew had a lot of tooling around both of those already (fetching and publishing), so it wasn't as big of a lift for that project.

Using GitHub Packages is a great idea! 🤔

[eregon]

FYI, you could follow an approach similar to https://github.com/ruby/ruby-builder
It would need to be OS and OS version and architecture specific at minumum.

More might be needed, e.g., if libssl is installed by Homebrew, or MacPorts or Homebrew in a non-standard location on macOS. But that might not be an issue given that ruby-build builds its own openssl for CRuby.

I think building movable Rubies is hard and brittle (#1760 (comment)), so I'd think that would be a non-goal, only use binaries if they are installed to the expected location.

Ultimately it would be best if CRuby itself would provide builds for various OS/OS version/arch, JRuby & TruffleRuby already do. That might be worth opening a ticket at https://bugs.ruby-lang.org/

[hsbt]

I prefer to use the binaries from ruby/ruby-builder instead of binaries of RVM because they are built by ruby-build and uses github packages.

[technicalpickles]

Some relevant details from ruby-builder 1 2:

const releasesURL = 'https://github.com/ruby/ruby-builder/releases'

function getDownloadURL(platform, engine, version) {
  let builderPlatform = platform
  if (platform.startsWith('windows-')) {
    builderPlatform = 'windows-latest'
  } else if (platform.startsWith('macos-')) {
    builderPlatform = 'macos-latest'
  }

  if (common.isHeadVersion(version)) {
    return getLatestHeadBuildURL(builderPlatform, engine, version)
  } else {
    return `${releasesURL}/download/${builderReleaseTag}/${engine}-${version}-${builderPlatform}.tar.gz`
  }
}

Note: they are using releases not packages, which is a little easier for downloading.

[wlnirvana]

any updates?

[eregon]

I prefer to use the binaries from ruby/ruby-builder instead of binaries of RVM because they are built by ruby-build and uses github packages.

That's not directly possible because those CRuby binaries are not movable (ruby/setup-ruby#98 (comment)) and so they only work if installed under /opt/hostedtoolcache/Ruby/$VERSION/x64 (linux) / /Users/runner/hostedtoolcache/Ruby/$VERSION/x64 (macOS).

So either someone can find how to make properly-working movable CRuby builds (I think it's hard, likely needs some hacks and I'm not willing to do it, but it seems possible), or there could be a separate set of builds (e.g., another repo like ruby-builder) which for instance expects the install location to be ~/.rbenv/versions (or potentially ~/.rubies for compatibility with chruby, but then we'd need an easy to configure rbenv to use that, or maybe even change the default of rbenv).