Glossary

Definitions of the terms used throughout these guides.

binstub

A small wrapper script that Bundler generates into an application’s bin/ directory with bundle binstubs GEM. Running a binstub loads the bundle first, so the command runs against the exact gem versions in Gemfile.lock without needing a bundle exec prefix. See the bundle binstubs reference.

bundled gem

A gem that is installed automatically when you install Ruby but is not part of Ruby itself. Unlike a default gem it can be uninstalled, and when using Bundler it must be declared in the Gemfile. See Default Gems and Bundled Gems.

cooldown

A Bundler setting that excludes gem versions published within the last N days from dependency resolution. Most malicious releases are detected and yanked within days of publication, so a cooldown keeps an application from installing a release before the ecosystem has had time to vet it. See How to delay new gem versions with cooldown.

default gem

A gem that ships as part of every Ruby installation. It can be required without appearing in a Gemfile and cannot be uninstalled, but it can be updated independently of Ruby. See Default Gems and Bundled Gems.

dependency

A gem that another gem or an application needs in order to work. Gems declare their dependencies in the gemspec and applications declare theirs in the Gemfile, and each dependency can bring dependencies of its own, forming the graph that resolution works on. See Gemfile and gemspec.

gem

A packaged Ruby library or program. Each gem has a name, a version, and a platform, and contains code, documentation, and a gemspec. See What is a gem?.

Gemfile

The file that describes an application’s gem environment for Bundler. It lists the gems the application uses directly, along with the sources to fetch them from. The file does not have to be named Gemfile: Bundler also recognizes gems.rb, and the BUNDLE_GEMFILE environment variable can point to any file. See Gemfile and gemspec and the Gemfile reference.

Gemfile.lock

The file Bundler writes after dependency resolution, recording the exact version of every gem, direct or transitive. Often called simply the lockfile, and named after the Gemfile when that file uses another name, such as gems.locked for gems.rb. Later installs reuse those versions instead of resolving again, so every machine and every deploy runs the same code. Bundler maintains the file, and you never edit it by hand. See How Gemfile.lock works.

gemspec

The manifest of a gem. It declares the gem’s name, version, summary, files, and dependencies, and it is packaged into the .gem file that gem build produces. See the Specification Reference.

lockfile checksums

The CHECKSUMS section of Gemfile.lock, recording the SHA-256 digest of each packaged .gem file. Bundler verifies every gem against its checksum during installation, so a gem that was tampered with after the lockfile was written fails to install. See Lockfile checksums.

native extension

Code, typically C, that is part of a gem and is compiled on the user’s machine at install time, often to wrap an existing system library. Building one requires a compiler toolchain and the library’s development headers. See Gems with Extensions.

platform

The CPU architecture, operating system type, and sometimes operating system version a gem is built for. The generic ruby platform means pure Ruby code that works on any platform Ruby runs on. See What is a gem?.

precompiled gem

A gem published in platform-specific variants with its native extension already compiled, so installation skips the compile step and needs no toolchain. Also called a fat gem. The platforms a lockfile covers for such gems are recorded in its PLATFORMS section. See How Gemfile.lock works.

prerelease

A version containing a letter, like 1.0.0.pre or 2.0.0.rc1, published for testing before the real release. Installers and the resolver ignore prereleases unless a requirement explicitly names one. See Versioning and compatibility.

requirement

One or more comparisons against a version, like >= 1.0 or ~> 2.2, stating which versions of a dependency are acceptable. Also called a version constraint. See How dependency resolution works and Versioning and compatibility.

resolution

The process of choosing exactly one version of every gem in the dependency graph so that all requirements hold at the same time. Bundler runs it on the first bundle install and writes the result to Gemfile.lock. See How dependency resolution works.

source

A place gems are fetched from: a gem server such as RubyGems.org, a git repository, or a local directory. Sources are declared in the Gemfile, and each one gets its own block in Gemfile.lock. See How Gemfile.lock works.

trusted publishing

A way to publish gems from CI without long-lived credentials. A configured workflow authenticates with RubyGems.org using short-lived OpenID Connect tokens, so there is no API key to create, rotate, or leak. See Trusted Publishing.

vendoring

Storing copies of an application’s dependencies inside its own repository, so installs do not need to reach a remote source. bundle cache puts the packaged .gem files of the bundle into vendor/cache. See the bundle cache reference.

yank

Removing a published version from RubyGems.org with gem yank. A yanked version can no longer be installed, but the name and version number stay taken and cannot be reused. See Removing a published gem.