Ruby-build: Make ruby-build usable on linux distros

[m-o-e]

root@foo:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:    16.04
Codename:   xenial

root@foo:~# apt-get install ruby-build

Reading package lists... Done
Building dependency tree
Reading state information... Done
ruby-build is already the newest version (20151028-1).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.

The packaged version of _ruby-build_ is currently useless on most
linux distributions because their package update interval doesn't
keep up with the _ruby-build_ update cycle.

_ruby-build_ should stop embedding the definitions and
should rather download and maintain them in a data directory.

I.e. ruby-build --update should become a thing.

This way _ruby-build_ will become usable out of the box even
on distros such as Ubuntu LTS, where the newest packaged version
tends to be very old.

[jasonkarns]

ruby-build already supports the use of additional build definitions by providing RUBY_BUILD_DEFINITIONS (colon-separated list of paths to search for addition build defs)

For instance, use of this plugin https://github.com/jasonkarns/ruby-build-update-defs would support the use case you describe.

[m-o-e]

I know there's many ways to _make_ it work but my point is: it should just work out of the box.

If another plugin is needed to allow the ruby-build plugin
to perform its single purpose then the distro packages
should include it.

There is no good reason to require manual extra steps
from every ruby-build user.

The following line should just work on any Debian or Ubuntu version:
apt-get install rbenv ruby-build && rbenv install $latest_ruby_version

And ruby-build should auto-update its definitions by default.

The computer should be doing the hard work. That's what it's paid to do, after all.
-- Larry Wall

[jasonkarns]

Not sure those are all "shoulds" considering the tradeoffs involved. The static build definitions provide quite a bit of value that would be lost with dynamic "install whatever is latest". Any custom packages that need installed for a given ruby; dealing with versions of yaml or readline or openssl; custom build flags necessary for given releases or workarounds for issues/patches. As you can see in many of the build definitions (and in the history of the /share directory in particular), these have all been actual scenarios at one point or another. "dynamic" build definitions would be susceptible to breakage as a result. In its current form, any build definition that is included will work out of the box. Dynamic build definitions offer no such guarantee and could break at any given moment, thus rendering CI boxes, build/deploy chains unusable.

Indeed, debian packages themselves are static in the exact same manner. (As are the homebrew formula for the OSX community.) As you know, installing the latest version of ruby-build affords the ability to subsequently install the latest ruby. I fail to see why it should be a given that installing an _old_ version of ruby-build should support installing latest ruby. The underlying issue here is that the debian package is not updated frequently enough. So I'd suggest one of the alternative methods of installing ruby-build, as documented in the readme.

Obviously, I can't speak for the original author(s) or even current maintainers, but I believe the current architecture was designed for stability above all. The plugin architecture thus affords users the ability to "sacrifice" said stability for flexibility, if so desired. As for how to install ruby-build itself, there are many options, each with tradeoffs, that leave the decision to you.

[jasonkarns]

To be clear, I sympathize with your issue (which is why I wrote ruby-build-update-defs in the first place :) )

[jeremy]

Hey @m-o-e, thanks for weighing in. This is a duplicate of #51.

@jasonkarns covers the pressures at play. If the definitions were only a collection of Ruby version identifiers and URLs to fetch, then using a separate, updatable manifest could be straightforward. The definitions use the ruby-build API to perform builds, however, so definitions would need to be branched and updated separately for each ruby-build release in the wild. This can certainly be implemented, but should it?

Some options that may be a more natural fit:

• Rely on a PPA for software packages with these characteristics.
• Volunteer to maintain the upstream ruby-build packages and backport new ruby-build definitions to the build API in the older release.

(Explicit social cue: You're using a brusque, exaggerated communication style that, while it does get across your sense of this feature as a basic necessity, also carries a message of condescension and scorn that you may have not intended. This sets up for an adversarial exchange instead of a constructive one.)

[m-o-e]

Cue taken, I apologize for the tone and thanks for your elaborate replies.

It's been one of those late night tickets after having had to explain one
too many times how to find and update the definitions on linux.

[JasonBarnabe]

To save some future people's time, if you installed via your distro's package manager, are using the latest version, and you get "definition not found"

$ rbenv install 2.5.1
ruby-build: definition not found: 2.5.1

then download the file from this repo (https://github.com/rbenv/ruby-build/tree/master/share/ruby-build), then reference it instead of the version number:

$ rbenv install ./downloaded-file
Downloading ruby-2.5.1.tar.bz2...