Add support for downloading truffleruby-head

[eregon]

• Uses the latest nightly, which is automatically built.
• Similar to https://github.com/rbenv/ruby-build/pull/1405

Only the URL changes, the way to install remains exactly the same.

Corresponding one-line change in ruby-versions: https://github.com/postmodern/ruby-versions/pull/48

Ref: https://github.com/oracle/truffleruby/issues/1483 We want to make it easy for users to try the latest TruffleRuby nightly.

This PR allows:

$ ruby-install truffleruby head
>>> Installing truffleruby head into /home/eregon/.rubies/truffleruby-head ...
>>> Installing dependencies for truffleruby head ...
...
>>> Downloading https://github.com/ruby/truffleruby-dev-builder/releases/latest/download/truffleruby-head-ubuntu-18.04.tar.gz into /home/eregon/src ...
...
>>> Verifying truffleruby-head-ubuntu-18.04.tar.gz ...
*** No md5 checksum for /home/eregon/src/truffleruby-head-ubuntu-18.04.tar.gz
*** No sha1 checksum for /home/eregon/src/truffleruby-head-ubuntu-18.04.tar.gz
*** No sha256 checksum for /home/eregon/src/truffleruby-head-ubuntu-18.04.tar.gz
*** No sha512 checksum for /home/eregon/src/truffleruby-head-ubuntu-18.04.tar.gz
>>> Extracting truffleruby-head-ubuntu-18.04.tar.gz to /home/eregon/src/truffleruby-head ...
>>> Installing truffleruby head ...
>>> Running truffleruby post-install hook ...
...
>>> Successfully installed truffleruby head into /home/eregon/.rubies/truffleruby-head

cc @havenwood @postmodern @deepj

[havenwood]

If I recall correctly, @postmodern has declined PRs supporting head or nightly installs in the past. It's mentioned as an anti-feature in the README:

Does not support installing trunk/HEAD.

[eregon]

Right, that's in the README. My understanding of it is ruby-install doesn't want the complexity to install from source (except MRI releases) / from the source repository. Which I understand, for instance building MRI trunk needs extra make commands such as make update-gems and extra packages.

However, this PR has nothing to do with building from source, and the complexity increase seems very reasonable. In fact, it's still quite a bit shorter than https://github.com/postmodern/ruby-install/blob/master/share/ruby-install/ruby/functions.sh.

[postmodern]

@havenwood is correct here.

I made the explicit decision not to support installing from HEAD, as that is prone to compilation errors or installing a buggy ruby. Any compiler errors or weird bugs would likely be reported by users back to ruby-install, instead of upstream, under the assumption that it was a problem with ruby-install and not upstream HEAD. Furthermore, HEAD is a moving target which makes reproducing any errors very difficult. This is simply extra triage work we do not want to take on.

If you want to make it easier for developers to get involved with TruffleRuby, then I highly recommend adapting truffleruby/functions.sh into a script that sets up a full truffleruby development environment and then installs from HEAD or other branches. This way you would have separate installation paths for regular users (stable releases) and for developers/contributors/QA testers (bleeding edge HEAD/branches).

[eregon]

That's disappointing :disappointed: I think most points you mentioned don't apply, let's go through them.

that is prone to compilation errors

Not in this case, it's prebuild just like releases.

or installing a buggy ruby.

Whatever gets in truffleruby master has passed all tests of the TruffleRuby CI (specs, MRI tests and many more). Also, the nightly builder makes some sanity tests. So applies very little. If you're concerned about bug reports, I'd be happy to handle any TruffleRuby-related issue reported here.

HEAD is a moving target which makes reproducing any errors very difficult

The git hash is shown in ruby -v. The error would likely still apply for newer builds, and if it doesn't there is no issue anymore.

Building a TruffleRuby distribution from source is of course more complicated than ruby-install truffleruby head, and is also rather memory-intensive. So not a good idea for people wanting to test latest TruffleRuby and e.g. verify bug fixes, as we have experienced in https://github.com/oracle/truffleruby/issues/1483.

[eregon]

So I guess I'll just recommend anyone wanting to install TruffleRuby head to just switch to ruby-build then.

[havenwood]

@eregon I have a little script I use for nightly installs of CRuby: https://gist.github.com/havenwood/823382815cbdcfddadd798d4042023a8

Maybe we should create a ruby-install-head tool that compliments ruby-install?

[postmodern]

Whatever gets in truffleruby master has passed all tests of the TruffleRuby CI

Ah but how do you know your CI has complete and correct test coverage? ;) Does the CI run tests on every permutation of platform, platform release, and external dependency versions? Do you perform mutation testing, formal verification, or run SMT solvers, to ensure that the code and tests are correct and account for all edge-cases? MRI, JRuby, and Rubinius also have CIs, and yet they still have bugs slip into HEAD from time to time. CIs definitely help, but are not a 100% guarantee against bugs.

Furthermore, I've noticed that when projects provide nightly builds, it does attract beta-testers (which is desired), but it also entices some users to try the nightly builds which usually results in a negative user experience (which is obviously not desired) due to bugs or suddenly changes. I would suggest thinking more about the root problem you are really trying to solve by making it easier for users to try nightly builds of TruffleRuby. Perhaps it's an issue with your Release Engineering, QA, or Release Cycle? Or maybe the build system for GraalVM/TruffleRuby needs streamlining?

If you're concerned about bug reports, I'd be happy to handle any TruffleRuby-related issue reported here.

I prefer that any Ruby-specific issues unrelated to ruby-install always be submitted directly to it's respective upstream projects. That way no one has to triage, tell the user to report upstream, and close the issue. The less issue wrangling anyone has to do, the better.

I like the idea of a ruby-install-head or ruby-install-dev, but I'm still apprehensive about having issues submitted back to us, instead of upstream. Perhaps ruby-install-head/dev could be a template which Ruby projects would fork, fill out the necessary code, and maintain themselves?

[eregon]

Ah but how do you know your CI has complete and correct test coverage? [...]

No Ruby implementation has that. But releases neither. The only extra testing of releases is polyglot testing. Polyglot testing doesn't matter here, because only TruffleRuby is available in the TruffleRuby standalone distribution.

I prefer that any Ruby-specific issues unrelated to ruby-install always be submitted directly to it's respective upstream projects. That way no one has to triage, tell the user to report upstream, and close the issue. The less issue wrangling anyone has to do, the better.

Of course. I think the large majority of users would understand bugs in nightly builds should be reported to the Ruby implementation. In fact, I would think the opposite problem is more frequent: reporting to TruffleRuby when it's a Ruby installer bug. But still it's only a few occurrences over >5 years, and I don't mind those being reported to TruffleRuby first.

I think people more often report bugs about compiling MRI to Ruby installers, because they think it's the Ruby installer's fault, which it might or might not be. Not a concern here though, since there is very little compilation going when installing TruffleRuby (and the same recompilation of OpenSSL happens for releases too, did you get any TruffleRuby issue here? I think not).

Overall, I think generalizing issue reports from compilation errors of MRI to other head builds is incorrect, because there is far less compilation there. Yes, nightly builds might be a little bit less stable than releases, but that's in the name, and users understand that too.

[postmodern]

No Ruby implementation has that. But releases neither.

While technically true, the point I was trying to make was that CI is not a replacement for an actual Release Engineering process. A manual release involves more than just "did the CI pass", but also scheduling, a feature freeze, manual review, manual QA testing, alpha/beta/pre/rc releases, bug triage, blog posts/emails to notify users, etc. That additional work which goes into a manual release decreases the chances of bugs or other unwanted surprises reaching the end user; and in turn reduces the chance for issues to be erroneously submitted back to ruby-install/ruby-build/RVM. Not to mention, version numbers are much easier to read/understand than say random git sha1 checksums. I mean, when was the last time you heard someone say "oh cool, version 577f84e37 is out!"?

I think the large majority of users would understand bugs in nightly builds should be reported to the Ruby implementation.

This is an assumption. Based on my and @havenwood's experience with ruby-install, and from what I've seen in ruby-build and RVM's issue trackers, users most certainly do submit upstream bugs to their installers first. It's a logical first place to go, since the user used a piece of software and expect some degree of support when the software encountered an error. Part of the reason for not supporting installing from head is to reduce those erroneous bug reports; the other part being to protect users from "the bleeding edge" of Ruby implementations which can burn you.

Overall, I think generalizing issue reports from compilation errors of MRI to other head builds is incorrect, because there is far less compilation there. Yes, nightly builds might be a little bit less stable than releases, but that's in the name, and users understand that too.

The arguments I have made about the risks of automated builds vs. formal releases equally apply to JRuby, Rubinius, and TruffleRuby. Also remember that ruby-install cannot/should not cater to any one Ruby implementation. Even if there's technical arguments for the superiority of TruffleRuby's build system, ruby-install would also have to support an "install from head/nightly" option for MRI, JRuby, Rubinius. It's also unwise to assume every user understands the risks associated with installing head/nightly builds and will behave accordingly. Probably some users might understand the risks, but there's definitely others who would be curious about what new features or changes are in head/nightly; I used to be one of those users...

Anyways, I have already stated why I believe installing from head is considered an Anti-Feature wrt ruby-install and why I rejected the PR. Further debate is probably counterproductive here. I would rather see a solution tailored specifically for upstream developers/contributors, separate from ruby-install; I am sure there's a lot of cool development environment specific stuff we could do that would normally be out-of-scope for ruby-install.

[ioquatix]

I think this is a great PR and wish it was merged. It should also be possible for CRuby to install head and a specific SHA. It's very useful for ruby developers.

[eregon]

For the record, ruby-build can also be used with chruby and supports installing truffleruby-dev, documented in https://github.com/oracle/truffleruby/blob/master/doc/user/ruby-managers.md#ruby-install-and-chruby

[ioquatix]

I ended up applying this patch locally and can confirm it works as expected. There was another issue though, llvm-4.0 is no longer required but ruby-install still tries to install it (by macports).

[eregon]

The llvm-4.0 issue has been fixed ~8 months ago: https://github.com/postmodern/ruby-install/pull/359 Note this branch is already after that fix, so checking out this branch would work.

@postmodern Could you please do a 0.7.1 release with that fix?

[postmodern]

0.7.1 has finally been released!

[postmodern]

@ioquatix ruby-install explicitly does not install rubies from HEAD/master, because ruby-install is intended for end-users and not ruby implementation developers/testers. That said, I am considering writing a single-file script specifically to help quickly setup a dev environment for a ruby implementation.

[ioquatix]

I understand your logic and on the whole can agree with it, but I don't know if your assertion that normal users don't want to try out Ruby HEAD or a specific SHA for debugging reasons is correct.

As someone who is trying to use chruby and ruby-install to replace rbenv and rvm, this is a big limitation.

[eregon]

I think that it's frequent that Ruby users/developers (not ruby implementation developers) try e.g. the latest CRuby, JRuby or TruffleRuby. CRuby to try new features, JRuby/TruffleRuby to try the latest fix for a bug they reported. ruby-install makes it inconvenient, which is IMHO hurting those cases and potentially slowing down the feedback cycle.

Note that for JRuby and TruffleRuby there is no need to build "from source" as they both have pre-built and tested development builds. Building from the repository source is typically messy, so I understand ruby-install doesn't want to support that.

My recommendation is to use ruby-build + chruby, that works well together, and ruby-build supports -dev versions. Not many people know that though, as typically ruby-install is used with chruby, so I think it would be valuable to merge this PR.

[postmodern]

I already said I am considering writing a separate script to manage installing from HEAD. @ioquatix or @eregon could either of you explain to me why occasionally using a script other than ruby-install is a deal breaker?

@ioquatix I also would like to know how many times per week, per month, per year, that an "average" Ruby user needs to install a Ruby from HEAD (or a nightly build) in order to test whether a bug was fixed? Does this happen more often with CRuby, JRuby or TruffleRuby? I challenge that if users are needing to install from HEAD or test nightly builds frequently, it implies the upstream Ruby has release-engineering or QA issues that it needs to work through in order reach stability.

[eregon]

People would have to know about this new script, install it, etc. Might as well ask them to install ruby-build but obviously people prefer a consistent solution and not having to juggle with multiple scripts/tools. Installing a development release is still "installing a Ruby", so for me it makes sense to be in ruby-install.

Alternative Rubies typically do not have 100% compatibility with CRuby yet, yet early adopters might already want to try on an app or gem or run it in CI (and then potentially debug locally). IMHO better having a dev build in CI than nothing (some might disagree). There is a TruffleRuby release every 3 months, that's IMHO too infrequent for TruffleRuby but since it's part of GraalVM we have to agree on a release schedule. Maybe you can consider that a release-engineering issue but that's how things are since the very beginning and seems unlikely to change. I suppose TruffleRuby could do an automated release every day or every week or every commit (seems kind of what Rubinius does). But then is that "automated release" any better than a development build? I say no.

So actually here we have a situation where Rubinius de facto has "dev builds" in ruby-install because Rubinius has so many and automated "releases" but TruffleRuby dev builds are not allowed because TruffleRuby does dev builds differently? (e.g., don't include a number but a date as version, the tag is on a different repo, old dev builds are removed automatically). From a GitHub point of view, TruffleRuby dev builds are releases: https://github.com/ruby/truffleruby-dev-builder/releases

Any issue reporter to JRuby or TruffleRuby would tell you development builds are super valuable to test a fix. IMHO it's unfortunate ruby-install doesn't support them yet, when there seems to be no technical reason behind it.