👍

I’ve opened #863, which should check the first two boxes.

As for the third, I don’t know what to say on wiki besides, “Support for Rubinius was removed at the request of its maintainer” with a link back to this comment. I guess I’ll start with that and others can edit it if they have more to say.

I'm a little bit sad that this would undo many hours or debugging, user support, and workarounds that I've invested in bringing easier Rubinius support to ruby-build and rbenv. Examples:

• 3e5c31f - Support Rubinius linking against Homebrew openssl
• 3b6f96d - Lookup LLVM 3.5 from Homebrew on require_llvm on OS X
• 9a5256e - Work around Rubinius LLVM incompatibilities on Yosemite
• dbd8c71 - Fix Rubinius gem binstubs path

However, even if after all this, our rbx support is deemed unwelcome, then I'm 👍 if someone is going to put in work to remove this, document it, and provide support to people who will undoubtedly come to the Issues section to ask about this.

I didn't request that Rubinius be removed; that's @sstephenson's revisionism, just as this is https://twitter.com/sstephenson/status/682300372766068737.

What I said was, "given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius."

You are welcome to choose to remove support for Rubinius, just as you are welcome to follow the repeated requests from me to follow my recommendations for the project. Take ownership for your decision.

Here's my suggestion, "The rbenv maintainers don't like how Rubinius chooses to run their project and we don't want to work with their recommendations for building because we think our way of doing things is more important, so we are removing support for installing Rubinius. Ultimately, we think our tool's 'philosophy' is more important than being useful to people."

@brixen in #860 you mentioned:

If a failure happens during building artifacts, we rebuild them. If something is borked when we label a release, we relabel it.

How absolute is this idea? If you release v2.10, then v2.11, then finally v2.12, would it be safe to assume that v2.10 and v2.11 won't change from a git tag and tarball hash perspective, since they're not the latest, and thus not subject to the same level of disruption that comes with releasing a potentially broken new version? Or does the tarball and git tag mutability also extend beyond the latest release?

I ask because, first, I can't see what problems would be solved by keeping historical release labels and tarballs mutable over time (scoped, perhaps, to within a MAJOR.x set of releases), and, second, perhaps there is some compromise here between rbenv and Rubinius. Rubinius would be able to keep its definition of a release label, and rbenv (and no doubt many others) might be able to retain its preference for reproducibility and identifiers themselves as the means for signalling.

(A separate thought would be to have a scheme like v2.10-1, v2.10-2, where MAJOR.MINOR-REL is such that the -REL indicates a release counter, and a MAJOR.MINOR release identifier would map to one or more MAJOR.MINOR-REL artifact identifiers. That doesn't really address git tag mutability, though.)

@sstephenson has always been my personal hero but from now on he will be my personal superhero (sorry, Chris Evans)

@aprescott see this comment and the following one.

A Rubinius release is a tuple of (version, SHA). A release is not mutable. The most current tuple of (version, SHA) is the correct one. The only version label whose SHA may change would likely be the most current one. But that doesn't actually matter at all. rbenv should not cache the version git SHA (or release tarball SHA), or it should provide a mechanism to update it.

You are welcome to choose to remove support for Rubinius, just as you are welcome to follow the repeated requests from me to follow my recommendations for the project. Take ownership for your decision.

Reaching a decision is what this tracking issue is all about. It's clear to me that, whilst opening this issue, @sstephenson acted out of emotion, reacting to your apparent thanklessness for the work we put in ruby-build to help bring Rubinius (among other Ruby versions) to developers.

I see perfectly valid arguments from both sides:

• I continue to frown upon republishing tagged tarballs and I'm fairly confident that most of the wider UNIX software-consuming community will back me on this. Earlier this year, you hinted that you will avoid republishing rubinius-2.2.10.tar.bz2 changed its checksum rubinius/rubinius#3380 (comment), but I understand that it was in informal conversation and not a contract of any kind. I also believe ruby-build (tandem with rbenv), RVM, and ruby-install (tandem with chruby) deserve more credit for being on the front lines and catching a lot of build problems that eventually get reported upstream.
• On the other hand, none of us have a right to school you about how to manage releases of your own Ruby implementation, I acknowledge that you never explicitly requested what we drop rbx from ruby-build, and you do have a point about HTTP protocol providing a mechanism for caching, even if support for that might not be widely implemented by package managers (to my knowledge).

We have several options here:

1. Remove rbx support from ruby-build. That's what was originally proposed here.
   • Less code to manage saves maintenance time in the long run.
   • Users might suffer from repercussions of such change.
2. Remove checksums from rbx definitions.
   • This will allow rbx tarballs getting republished.
   • It will disallow transparent mirroring service that ruby-build provides. (Not a big deal.)
   • There won't be a guard against corrupt downloads anymore. (Not a big deal.)
   • Optionally, provide a mechanism for installing the latest version of anything using ruby-build. This would address @brixen's desire to encourage always installing the latest version of rbx.
3. Change absolutely nothing about our approach.
   • When we notice a tarball was republished, we simply update the checksum.

Personally, I'm leaning towards (2) over (1).

@brixen sure, I know your stated definition of a Rubinius release means that it's not mutable. I was trying to open this issue up to a situation where the conflicting outcomes of different views on a release can lead to Rubinius remaining part of well-used toolchains.

A SHA is immutable and unique. I'm not sure I understand why a version number is even meaningful here when you can't have X.Y.[specific SHA] and also A.B.[the same SHA]. If a version number is not an immutable alias for an immutable SHA, then what good is it?

A Rubinius release is a tuple of (version, SHA).

To be more specific: a SHA is unique. Attaching a version number to it is redundant. It also makes version numbering totally irrelevant if you have to have the SHA to actually identify a specific version of a project. Again, if a version number is not immutably tied to a SHA, then it means nothing. Perhaps Rubinius should just abandon version numbers altogether? As it stands now, they're not useful for anything.

Of course, I subscribe to the hopelessly outdated idea that a version number refers to a specific version, which is in turn a specific immutable SHA in git. But I have old-fashioned ideals about reproducible deployments.

@mislav I'd prefer you not cache tarball digest SHAs and install the version the user requests, whatever that is at the time the user requests it.

You can curl http://releases.rubinius.com/index.txt for available versions and fetch them and their digests from https://rubinius-releases-rubinius-com.s3.amazonaws.com/

If you want to cache the digest SHA locally and notify the user that the local cache (ie installed version) is no longer current, you could do that.

@mislav as I commented here, there is no difference between the Rubinius scheme with (version, git SHA) and MRI's with X.Y.ZpN. Previously, MRI never included the pN in the version number, and you can in fact find multiple 1.8.7, etc. It appears to do so now, which is great, but all the hand-wringing about "how will a user know?" is really over-blown.

You can list the Rubinius installs in your index as X.Y-gitSHA, if that's what you prefer. In the end, a release is a definite, distinguishable entity. Most people will not care about the gitSHA, for those that do, it's visible in RUBY_DESCRIPTION:

$ ruby -e 'puts RUBY_DESCRIPTION'
rubinius 2.10 (2.1.0 14deac8c 2015-12-26 3.5.1 JI) [x86_64-darwin15.2.0]

so looking at a list of

rbx-2.1.5ba9674
rbx-2.1.5bd3523
rbx-2.1.9c5fae4

which would be the most up to date?

@mislav I just found this issue and maybe an hybrid approach between (2) and (3) could be possible.

Just an idea but, what if ruby-build checks the SHA but instead of rejecting the install, it could warn the user of the mismatch and ask him if he wants to proceed.

I believe you get pretty much all the benefits from both worlds with an ocasional warning that the user can manually check on Rubinius' website

@trinode there is zero confusion about what is current. At the time you install, there is only one version X.Y for any X and Y. The only problem here is that rbenv wants to cache which git SHA a particular X.Y refers to. There's no reason to cache them, and if rbenv insists on caching them for some reason, it should either 1. provide a mechanism to update the cache, or 2. automatically update the cache.

If you look at https://github.com/rubinius/rubinius/releases, there is only one 3.2, one 3.1, etc. You'll never have a case of not knowing which is the current one.

@brixen sometimes consistent / repeatable is more important than current in muti-server environments.

Just an idea but, what if ruby-build checks the SHA but instead of rejecting the install, it could warn the user of the mismatch and ask him if he wants to proceed.

@sagmor I think that would make the feature even more complex, both for users and to maintain code-wise. Generally, it's not a good idea for unix utilities to have an interactive (i.e. blocking) mode that kicks in unpredictably, especially ruby-build which is likely used in provisioning scripts. It's better for a command to fail than to ask on stdin for how to proceed.

Also, ruby-build has an option to take in a patch via stdin to be applied to Ruby source before it gets compiled, and it that case it wouldn't be possible to prompt for user input on stdin.

@trinode

sometimes consistent / repeatable is more important than current in muti-server environments

Sometimes? I'd say all the time. I'm yet to see a production system and engineers maintaining it that can tolerate variable versions because it's "current".

Personally, my vote is for (2).

Since rubinius doesn't appear to keep previous builds of the same version available for download, there really isn't any potential for repeatable installs without some kind of rubinius archive. As for users enabling rbenv to manage multiple same-version builds, this seems like a feature that could be resolved with an rbenv plugin. I would imagine it functioning very similarly to rbenv-aliases, but keeping a record of rubinius build checksums and/or install timestamps, and simply aliasing to the latest one.

What if, per @brixen's recommendation, we had a rbx-latest definition that figures out the latest Rubinius release, downloads and installs it, and in the process dereferences the version so the final install ends up in a directory named rbx-X.Y? We would have to add a feature to ruby-build that can dereference a version number mid-install.

There would be no checksums, no trying to catch up with Rubinius releases manually (now happening almost daily), and people would be always installing the latest version.

I suggest to use rbx-3 and rbx-2. rbx-3 reference to latest version of rubinius 3.x series. rbx-2 is same behaivior with rbx-3 ref. #883 (comment)

@mislav the rbx-latest idea is very nearly accomplished (by users) if the ruby-build-update-defs plugin is used.

1. user runs rbenv update-version-defs, which creates build defs for the latest versions of rbx (sans checksums)
2. user can then rbenv install rbx-X.Y

I like the idea in that it removes the need for frequent ruby-build releases. (Which was the same reason for node-build-update-defs in the first place) But I'm not excited about how much code would be added to ruby-build to support it. Would version derefencing code be added for other ruby runtimes as well? As a user, I'd expect it to be similar across the board. That could be a lot of code.

Short story :

As a (very) casual developper, if ruby-build does not support rubinius, I will never test it.
As a sysadmin, if rubinius releases are not reliable, I will never use it in production.

Long story :

After reading #860 and here, I'm not sure I understand why rubinius tarballs change over time.
It seems it goes through (Tag git) => (Lots of processing) => (Tarballs).
And, from what I read, the processing can fail but still produce tarballs. Am I right ?

As a temporary solution, I agree with hsbt, ruby-build should just provide latest version.

If I could ask: does this mean that rubinius will not be supported in rbenv? (even for manually-installed setups)

@jf rubinius (or any other ruby) would still work in rbenv, if installed manually. rbenv makes no distinction how the ruby gets installed into $(rbenv root)/versions/. So long as it's in there, rbenv can use it.

Yeah, I would expect so too. I'm asking because I'm finding that rbenv rehash doesn't generate shims for binaries installed from gems when I use rubinius, and that's surprising to me. I've tried just pure rbenv, btw (so no gemset plugin), and the result is the same. Gems that come with binaries do not get recognized, and rbenv rehash does not generate shims for them.

Rubinius seems unmaintained. (FYI rubinius/rubinius#3813)

There is no specific reason for removing rbx definitions and maintained them in the future. They are the same as REE and Ruby 1.8 and 1.9 definitions today.