Top Related Projects
Quick Overview
ruby-build is a command-line utility that simplifies the process of installing Ruby versions. It works as a plugin for rbenv, allowing users to easily compile and install different versions of Ruby from source. ruby-build can be used standalone or as an rbenv plugin to automate the installation of Ruby interpreters.
Pros
- Supports a wide range of Ruby versions, including legacy and pre-release versions
- Easy to use and integrates seamlessly with rbenv
- Allows for custom build configurations and patching
- Regularly updated to support new Ruby releases
Cons
- Requires compilation from source, which can be time-consuming on slower machines
- May require additional system dependencies to be installed
- Limited to Unix-like systems (Linux, macOS, etc.)
- Occasional issues with specific Ruby versions or system configurations
Getting Started
To install ruby-build as an rbenv plugin:
mkdir -p "$(rbenv root)"/plugins
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
To install ruby-build as a standalone tool:
git clone https://github.com/rbenv/ruby-build.git
cd ruby-build
./install.sh
To install a Ruby version using ruby-build:
rbenv install 3.2.2
Or, if using standalone:
ruby-build 3.2.2 /usr/local/ruby-3.2.2
Competitor Comparisons
Manage your app's Ruby environment
Pros of rbenv
- Provides a lightweight, flexible Ruby version management system
- Allows per-project Ruby versions without modifying the global environment
- Integrates seamlessly with shell environments for automatic version switching
Cons of rbenv
- Requires separate installation of ruby-build for installing Ruby versions
- May have a steeper learning curve for beginners compared to all-in-one solutions
- Lacks built-in gemset management functionality
Code Comparison
rbenv:
# Set local Ruby version
rbenv local 3.0.0
# Set global Ruby version
rbenv global 3.1.2
# List installed versions
rbenv versions
ruby-build:
# Install a specific Ruby version
ruby-build 3.0.0 ~/.rbenv/versions/3.0.0
# List available Ruby versions
ruby-build --definitions
# Install Ruby with specific options
RUBY_CONFIGURE_OPTS="--with-openssl-dir=/usr/local/opt/openssl" ruby-build 3.1.2 ~/.rbenv/versions/3.1.2
rbenv focuses on managing Ruby versions, while ruby-build is specifically designed for installing Ruby versions. They are often used together, with rbenv providing the version management framework and ruby-build handling the installation process.
Ruby enVironment Manager (RVM)
Pros of RVM
- All-in-one solution for managing Ruby versions and gemsets
- Supports system-wide and user-specific installations
- Extensive documentation and large community support
Cons of RVM
- More complex and can modify shell environment
- Potential conflicts with other Ruby version managers
- Slower startup time due to shell script loading
Code Comparison
RVM installation:
\curl -sSL https://get.rvm.io | bash -s stable
rvm install 3.0.0
rvm use 3.0.0
ruby-build (with rbenv) installation:
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
rbenv install 3.0.0
rbenv global 3.0.0
Both RVM and ruby-build (used with rbenv) are popular tools for managing Ruby versions. RVM offers a comprehensive solution with built-in gemset management, while ruby-build focuses solely on installing Ruby versions and works seamlessly with rbenv for version switching.
RVM's all-in-one approach can be convenient for some users, but it may introduce complexity and potential conflicts. ruby-build, when used with rbenv, provides a more lightweight and modular solution, allowing users to choose additional plugins as needed.
Ultimately, the choice between RVM and ruby-build depends on personal preference and specific project requirements.
Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
Pros of asdf
- Supports multiple languages and tools, not just Ruby
- Single tool for managing versions of various technologies
- Extensible plugin system for adding new language support
Cons of asdf
- Steeper learning curve due to broader functionality
- May be overkill for projects focused solely on Ruby
- Potentially slower performance compared to specialized tools
Code Comparison
ruby-build:
# Installing a specific Ruby version
ruby-build 2.7.2 ~/.rbenv/versions/2.7.2
# Setting global Ruby version
rbenv global 2.7.2
asdf:
# Installing a specific Ruby version
asdf plugin add ruby
asdf install ruby 2.7.2
# Setting global Ruby version
asdf global ruby 2.7.2
Summary
ruby-build is a plugin for rbenv that focuses specifically on building and managing Ruby versions. It's lightweight and straightforward for Ruby-centric projects. asdf, on the other hand, is a more versatile version manager that supports multiple languages and tools through its plugin system. While asdf offers greater flexibility, it may introduce additional complexity for users who only need Ruby version management. The choice between the two depends on project requirements and personal preferences for simplicity versus versatility.
Changes the current Ruby
Pros of chruby
- Lightweight and minimalistic, with a smaller codebase
- Faster Ruby version switching due to simpler implementation
- Doesn't modify Ruby's
$PATH
, preserving system integrity
Cons of chruby
- Lacks built-in Ruby installation capabilities (requires separate ruby-install tool)
- Less extensive ecosystem and plugin support compared to rbenv
- May require more manual configuration for some advanced use cases
Code Comparison
chruby:
source /usr/local/share/chruby/chruby.sh
chruby ruby-3.0.0
ruby-build (used with rbenv):
rbenv install 3.0.0
rbenv global 3.0.0
Key Differences
- Installation: ruby-build (with rbenv) provides a more integrated solution for installing and managing Ruby versions, while chruby focuses solely on switching between pre-installed versions.
- Performance: chruby is generally faster for version switching due to its simpler approach.
- Ecosystem: rbenv has a larger ecosystem with more plugins and integrations available.
- Philosophy: chruby aims for simplicity and minimal interference with the system, while rbenv provides a more comprehensive Ruby version management solution.
Both tools are popular choices for Ruby version management, with the choice often coming down to personal preference and specific project requirements.
Node version management
Pros of n
- Simpler and more lightweight installation process
- Faster version switching due to its design
- Supports both Node.js and io.js versions
Cons of n
- Less granular control over Ruby versions and patches
- Fewer advanced features for managing multiple Ruby environments
- Limited support for system-wide installations
Code Comparison
n:
n 14.17.0
n latest
n lts
ruby-build:
ruby-build 3.0.1 ~/.rbenv/versions/3.0.1
rbenv install 3.0.1
rbenv global 3.0.1
Summary
n is a lightweight and fast version manager for Node.js, offering quick installation and version switching. It's ideal for developers who prioritize simplicity and speed. However, it lacks some of the advanced features and granular control provided by ruby-build.
ruby-build, on the other hand, offers more comprehensive Ruby version management with support for various patches and system-wide installations. It integrates well with rbenv, providing a robust environment for Ruby development. However, its installation process and version switching may be slightly more complex compared to n.
Choose n for a straightforward Node.js version management experience, or opt for ruby-build if you need more advanced Ruby version control and environment management capabilities.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
ruby-build
ruby-build is a command-line tool that simplifies installation of any Ruby version from source on Unix-like systems.
It is available as a plugin for rbenv as the rbenv install
command, or as a standalone program as the ruby-build
command.
Installation
Homebrew package manager
brew install ruby-build
Upgrade with:
brew upgrade ruby-build
Clone as rbenv plugin using git
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build
Upgrade with:
git -C "$(rbenv root)"/plugins/ruby-build pull
Install manually as a standalone program
First, download a tarball from https://github.com/rbenv/ruby-build/releases/latest. Then:
tar -xzf ruby-build-*.tar.gz
PREFIX=/usr/local ./ruby-build-*/install.sh
Usage
Basic Usage
# As a standalone program
$ ruby-build --list # lists latest stable releases for each Ruby
$ ruby-build --definitions # lists all definitions, including outdated ones
$ ruby-build 3.2.2 ~/.rubies/ruby-3.2.2 # installs Ruby 3.2.2
$ ruby-build -d ruby-3.2.2 ~/.rubies # alternate form for the previous example
# As an rbenv plugin
$ rbenv install 3.2.2 # installs Ruby 3.2.2 to ~/.rbenv/versions/3.2.2
[!WARNING] ruby-build mostly does not verify that system dependencies are present before downloading and attempting to compile Ruby from source. Please ensure that all requisite libraries such as build tools and development headers are already present on your system.
Basically, what ruby-build does when installing a Ruby version is this:
- Downloads an official tarball of Ruby source code;
- Extracts the archive into a temporary directory on your system;
- Executes
./configure --prefix=/path/to/destination
in the source code; - Runs
make install
to compile Ruby; - Verifies that the installed Ruby is functional.
Depending on the context, ruby-build does a little bit more than the above: for example, it will try to link Ruby to the appropriate OpenSSL version, even if that means downloading and compiling OpenSSL itself; it will discover and link to Homebrew-installed instances of some libraries like libyaml and readline, etc.
Advanced Usage
Custom Build Definitions
To install a version of Ruby that is not available in ruby-build, you can specify the path to a custom build definition file in place of a Ruby version number.
# As a standalone program
$ ruby-build -d /path/to/3.4-custom /opt/rubies # installs to /opt/rubies/3.4-custom
# As an rbenv plugin
$ rbenv install /path/to/3.4-custom # installs to $(rbenv root)/versions/3.4-custom
You can also provide a directory of custom build definition files.
The path(s) will be searched along with ruby-build's bundled share/ruby-build/
directory.
(Perhaps a collection of 3rd-party build definitions published as a git repo,
or an organization's custom build definitions distributed in-house.)
# As a standalone program
$ RUBY_BUILD_DEFINITIONS=/path/to/custom/defs ruby-build --definitions # lists all available versions of Ruby, including custom defs
$ RUBY_BUILD_DEFINITIONS=/path/to/custom/defs ruby-build -d 3.5-custom /opt/rubies # installs to /opt/rubies/3.5-custom
# As an rbenv plugin
$ RUBY_BUILD_DEFINITIONS=/path/to/custom/defs rbenv install --list # lists all available versions of Ruby, including custom defs
$ RUBY_BUILD_DEFINITIONS=/path/to/custom/defs rbenv install 3.5-custom # installs to $(rbenv root)/versions/3.5-custom
Check out default build definitions as examples on how to write definition files.
Custom Build Configuration
The build process may be configured through the following environment variables:
Variable | Function |
---|---|
TMPDIR | Where temporary files are stored. |
RUBY_BUILD_BUILD_PATH | Where sources are downloaded and built. (Default: a timestamped subdirectory of TMPDIR ) |
RUBY_BUILD_CACHE_PATH | Where to cache downloaded package files. (Default: ~/.rbenv/cache if invoked as rbenv plugin) |
RUBY_BUILD_HTTP_CLIENT | One of aria2c , curl , or wget to use for downloading. (Default: first one found in PATH) |
RUBY_BUILD_ARIA2_OPTS | Additional options to pass to aria2c for downloading. |
RUBY_BUILD_CURL_OPTS | Additional options to pass to curl for downloading. |
RUBY_BUILD_WGET_OPTS | Additional options to pass to wget for downloading. |
RUBY_BUILD_MIRROR_URL | Custom mirror URL root. |
RUBY_BUILD_MIRROR_PACKAGE_URL | Custom complete mirror URL (e.g. http://mirror.example.com/package-1.0.0.tar.gz). |
RUBY_BUILD_SKIP_MIRROR | Bypass the download mirror and fetch all package files from their original URLs. |
RUBY_BUILD_TARBALL_OVERRIDE | Override the URL to fetch the ruby tarball from, optionally followed by #checksum . |
RUBY_BUILD_DEFINITIONS | Colon-separated list of paths to search for build definition files. |
RUBY_BUILD_ROOT | The path prefix to search for build definitions files. Deprecated: use RUBY_BUILD_DEFINITIONS |
RUBY_BUILD_VENDOR_OPENSSL | Build and vendor openssl even if the system openssl is compatible |
CC | Path to the C compiler. |
RUBY_CFLAGS | Additional CFLAGS options (e.g., to override -O3 ). |
CONFIGURE_OPTS | Additional ./configure options. |
MAKE | Custom make command (e.g., gmake ). |
MAKE_OPTS / MAKEOPTS | Additional make options. |
MAKE_INSTALL_OPTS | Additional make install options. |
RUBY_CONFIGURE_OPTS | Additional ./configure options (applies only to Ruby source). |
RUBY_MAKE_OPTS | Additional make options (applies only to Ruby source). |
RUBY_MAKE_INSTALL_OPTS | Additional make install options (applies only to Ruby source). |
NO_COLOR | Disable ANSI colors in output. The default is to use colors for output connected to a terminal. |
CLICOLOR_FORCE | Use ANSI colors in output even when not connected to a terminal. |
Applying Patches
Both rbenv install
and ruby-build
commands support the -p/--patch
flag to apply a patch to the Ruby source code before building. Patches are read from standard input:
# applying a single patch
$ rbenv install --patch 1.9.3-p429 < /path/to/ruby.patch
# applying a patch from HTTP
$ rbenv install --patch 1.9.3-p429 < <(curl -sSL http://git.io/ruby.patch)
# applying multiple patches
$ cat fix1.patch fix2.patch | rbenv install --patch 1.9.3-p429
Checksum Verification
All Ruby definition files bundled with ruby-build include checksums for packages, meaning that all externally downloaded packages are automatically checked for integrity after fetching.
See the next section for more information on how to author checksums.
Package Mirrors
To speed up downloads, ruby-build fetches package files from a mirror hosted on Amazon CloudFront. To benefit from this, the packages must specify their checksum:
# example:
install_package "ruby-2.6.5" "https://ruby-lang.org/ruby-2.6.5.tgz#<SHA2>"
ruby-build will first try to fetch this package from $RUBY_BUILD_MIRROR_URL/<SHA2>
(note: this is the complete URL), where <SHA2>
is the checksum for the file. It
will fall back to downloading the package from the original location if:
- the package was not found on the mirror;
- the mirror is down;
- the download is corrupt, i.e. the file's checksum doesn't match;
- no tool is available to calculate the checksum; or
RUBY_BUILD_SKIP_MIRROR
is enabled.
You may specify a custom mirror by setting RUBY_BUILD_MIRROR_URL
.
If a mirror site doesn't conform to the above URL format, you can specify the
complete URL by setting RUBY_BUILD_MIRROR_PACKAGE_URL
. It behaves the same as
RUBY_BUILD_MIRROR_URL
except being a complete URL.
The default ruby-build download mirror is sponsored by Basecamp.
Keeping the build directory after installation
Both ruby-build
and rbenv install
accept the -k
or --keep
flag, which
tells ruby-build to keep the downloaded source after installation. This can be
useful if you need to use gdb
and memprof
with Ruby.
Source code will be kept in a parallel directory tree ~/.rbenv/sources
when
using --keep
with the rbenv install
command. You should specify the
location of the source code with the RUBY_BUILD_BUILD_PATH
environment
variable when using --keep
with ruby-build
.
Getting Help
Please see the ruby-build wiki for solutions to common problems.
If you can't find an answer on the wiki, open an issue on the issue tracker. Be sure to include the full build log for build failures.
Top Related Projects
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot