HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rbenv
ruby-build
Shell2011–2024
rbenv / ruby-build

ruby-build

A tool to download, compile, and install Ruby on Unix-like systems.

Systems & Infrastructure
Explore on GitHubRead Hacker News discussions
11Distinct people
12Mentions
0Explicit recommenders
4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A tool to download, compile, and install Ruby on Unix-like systems.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2011-08-11 23:31:15 UTC to 2024-12-27 07:17:37 UTC.

01232011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC303
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC101
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC202
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC312
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

12 sources
LAC-Tech·Dec 27, 2024
Thanks for this. I used to use ruby a lot - mostly just because it's the nicest language for scripting things on unix. I can remember trying to get it set up a year or so ago and finding the process difficult (think I was using rvm). https://github.com/rbenv/ruby-build/wiki#suggested-build-env... probably good idea to point people here before they install ruby, since it'll compile for minutes then tell you it's missing a dependency, and you have to start the whole process over.
In Ruby 3.4.0
lloeki·Jul 29, 2018
I've been building and running OpenGL toy applications[0] on Mojave public betas without issue just to check on that. You just get lots of deprecation warnings at compile time that you can quench by defining GL_SILENCE_DEPRECATION. Excerpt: ./nsopengl_example.h:5:5: warning: 'NSOpenGLContext' is deprecated: first deprecated in macOS 10.14 - Please use Metal or MetalKit. [-Wdeprecated-declarations] NSOpenGLContext* _openGLContext; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:202:12: note: 'NSOpenGLContext' has been explicitly marked deprecated here @interface NSOpenGLContext : NSObject <NSLocking> ^ nsopengl_example.m:97:9: warning: 'glVertex3f' is deprecated: first deprecated
Read the rest
in macOS 10.14 - OpenGL API deprecated. (Define GL_SILENCE_DEPRECATION to silence these warnings) [-Wdeprecated-declarations] glVertex3f( 0.0, 0.6, 0.0); ^ Nothing is gone yet. I suspect they'll proceed in a similar way as with OpenSSL, first deprecate, then remove headers, and keep the libs around for quite some time for legacy applications. In Mojave public beta /usr/lib still contains libssl.0.9.7.dylib and libssl.0.9.8.dylib, and it's been quite some time (El Capitan [1]) since you haven't been able to build against them. The trickier part with OpenGL though is the graphic drivers. I suppose at some point in the future drivers for fresh new GPUs won't include OpenGL support. Maybe they'll include a GL-to-Metal akin to MoltenGL in that case, maybe not, or a third-party will create just that to run legacy applications. Anyway I bet it's a long road ahead and won't happen overnight. [0]: https://gitlab.com/lloeki/nsopengl_example [1]: https://github.com/rbenv/ruby-build/issues/797
In Discontinuation of Mac Support for Autodesk Alias and VRED
mhw·Jan 23, 2017
> Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of. The nearest equivalent is to place a file called '.ruby-version' in the top level directory, containing the version number of the Ruby you want to use. Version numbers come from https://github.com/rbenv/ruby-build/tree/master/share/ruby-b.... rbenv, chruby and rvm all support .ruby-version. One difference from virtualenv is that the Ruby version managers share single installations of each version of Ruby. My understanding from occasional use of Virtualenv is that it copies the python installation into a new per-project subdirectory, which seems a bit wasteful to me. > You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now. Yes, this is what I do. It gives m
Read the rest
e a shared 'clean' Ruby installation of the right version, plus a project-specific copy of all the gems the project depends on. To me this provides the best trade off between project isolation and not duplicating the whole world. You can set bundler up so this is done automatically by creating '~/.bundle/config' containing --- BUNDLE_PATH: "vendor/bundle" BUNDLE_BIN: ".bundle/bin" (The BUNDLE_PATH one is the important one; see 'bundle config --help' for other options.)
In Announcing Pipenv
dekz·Jan 20, 2016
The context of the tweet seems to be about Rubinius' versioning, to me, it is crazy. Not knowing if your prod 2.10 is the same as your local development 2.10, absolutely bonkers. > In Rubinius, a "version" is a label on a git commit. To find exactly which commit (uniquely identified by its SHA) the version labels, you deference the corresponding git tag. [1] Rubinius is so unwavering about their versioning process that they have asked to be removed from dev tools like rbenv and chruby. [2] @brixen then offers conflicting statements on where he stands with regards to this: Advocating removal: > Honestly, 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. [3] Denying removal: > I didn't request
Read the rest
that Rubinius be removed; that's @sstephenson's revisionism... [4] [1]: https://github.com/rbenv/ruby-build/pull/860#issuecomment-16... [2]: https://github.com/rbenv/ruby-build/issues/862#issuecomment-... [3]: https://github.com/rbenv/ruby-build/pull/860#issuecomment-16... [4]: https://github.com/rbenv/ruby-build/issues/862#issuecomment-... > Of course, choosing to build a system with a fundamental flaw in it is something they are perfectly free to do
In Charles Nutter of JRuby Banned by Rubinius for Harassment
bradleyland·Oct 7, 2013
> ...while on the server you suddenly are forced to use RVM. Why are you forced to use RVM on the server? A great number of the issues people face when trying to deploy Rails apps are environment based. Tools like rbenv and RVM are environment managers. They make all kinds of changes to things like PATH, GEM_HOME, etc. In a production server environment, you want consistency and simplicity. Yes, you can use tools like rbenv or RVM, you but add layers of environment management on top of the base server environment. When you use these tools to manage Ruby on your server, any process or daemon that needs Ruby will first have to ensure that these tools are loaded and invoked properly. It's a layer of indirection that I feel a strong incentive to avoid. Don't get me wrong. I'm not saying they're not good tools. Quite the opposite. I'm a huge f
Read the rest
an of RVM, rbenv, and chruby. I have a deep appreciation of their contribution to the Ruby ecosystem, but I'm one guy. I have a reasonable understanding of Linux system administration, but the more layers of complexity I add, the deeper the water gets. At some point, I'm in over my head. There are two really great options for installing Ruby on your production servers: Note: Most Linux distributions give /usr/local/bin priority in PATH by default, which is why I use it instead of /opt. Using /usr/local/bin means you don't need to modify PATH. 1) Use ruby-build [1]. This is the plugin that rbenv uses to install Ruby, and you can use it without rbenv. Once it is installed, this simple invocation will get you a working Ruby install: ruby-build '2.0.0-p247' '/usr/local' Because of the reasons outlined in the note above, this type of Ruby install will "just work", even for utilities that shell out with bare shells like `sh -c 'some command here'`. This is because we installed to paths that work with the bare minimum environment. 2) Install from source. In the example above, ruby-build really isn't doing all that much. You still have to have the basic deps (build-essential, zlip, ssl, readline) in place in order to build Ruby, and you have to remain aware of any caveats introduced by new OS or Ruby releases. I use option 2. A great way to keep up with what's required to install Ruby on your system is to look at what tools like rbenv and RVM are doing under the hood. These tools act as collectors for the little hacks and workarounds (e.g., ref URL 2 below) that are occasionally required to install Ruby. If you're running a mainstream distro on a recent release, you really shouldn't need much in the way of hacks/workarounds these days. OS X is where a lot of the trouble lies. 1: https://github.com/sstephenson/ruby-build 2: https://github.com/sstephenson/ruby-build/blob/master/bin/ru... EDIT: Above I said, "[ruby-build] isn't doing all that much", which isn't entirely fair. Ruby-build does do some really nice things like check MD5 hashes. It also checks for common caveats, which I kind of played off. I do the work of looking out for these things, but I'd certainly understand why someone wouldn't want the hassle, and ruby-build does a fantastic job of keeping up with these hassles and automating them away. In short, I want to be crystal clear that I am super appreciative of the work that the rbenv and RVM authors do. They are a tremendous asset to the community.
In Time to hand over the reins before Capistrano costs me my youth?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.