Package Managers

A bare rake starts through RubyGems, which activates the newest installed rake, not the one Gemfile.lock pins. bundle exec runs Bundler.setup first, so the command sees only the locked versions and only the bundle's gems.

In a Gemfile, ~> 3.1 is the pessimistic operator: at least 3.1 and below 4.0. ~> 3.1.4 allows 3.1.4 up to below 3.2, >= 3.1 has no upper bound at all, and a bare "3.1.4" means exactly = 3.1.4.

bundle install installs exactly the versions Gemfile.lock records and re-resolves only gems whose Gemfile entry changed. bundle update deliberately unlocks the named gems, or every gem with --all, and moves them to the newest versions the Gemfile allows.

require "bundler/setup" calls Bundler.setup, which puts the locked gems of all installed groups on the load path but loads none. Bundler.require runs setup and then requires every gem of the named groups, :default when called without arguments.

A group labels gems (ungrouped ones are in :default) so installs and Bundler.setup can include or skip them, yet every group still resolves into one Gemfile.lock. require: false keeps the gem installed and loadable but stops Bundler.require from requiring it automatically.

gem install puts a gem and its runtime dependencies into GEM_HOME, gem list shows installed versions, gem update adds the newest version beside the old one, and gem uninstall removes a version. Only gem cleanup or uninstall deletes old versions.

A .gemspec is Ruby code that builds a Gem::Specification: name, version, summary, authors, files, require_paths and dependencies. gem build validates it and packages the listed files into name-version.gem, the file gem push uploads.

GEM_HOME is the single directory gem install writes into; GEM_PATH is the list of directories RubyGems searches for installed gems, and GEM_HOME is always part of it. --user-install writes to Gem.user_dir, such as ~/.gem/ruby/4.0.0.

add_dependency declares a runtime dependency, installed and activated with your gem. add_development_dependency declares a tool needed only to work on the gem; gem install skips it unless --development is given, and it is never activated.

gem push uploads a built .gem using an API key from gem signin or GEM_HOST_API_KEY. With MFA enabled, the server demands a one-time code passed via --otp or GEM_HOST_OTP_CODE. Metadata rubygems_mfa_required and allowed_push_host harden pushes.

rvm install downloads a prebuilt Ruby or compiles one into ~/.rvm/rubies; rvm use switches only the current shell by rewriting PATH and the gem variables; adding --default also records it as the default alias that every new shell loads.

RVM hooks cd, sources shell code into every session, manages gemsets and system packages, and last tagged 1.29.12 in 2021; rbenv just selects a Ruby and leaves gems to Bundler. Migrating keeps .ruby-version and drops .rvmrc, .ruby-gemset and RVM.

RVM's selection is environment state set by a shell function your SSH login shell sources; cron's minimal shell never loads it, so no cd hook and no gemset. Use RVM wrappers, rvm in DIR do, or rvm cron setup.

A gemset is a named gem directory attached to one installed Ruby. rvm use 4.0.7@billing --create creates and selects ~/.rvm/gems/ruby-4.0.7@billing; new gems install there, while gems in that Ruby's @global gemset stay visible to it.

RVM's cd hook walks up from the new directory and loads the first project file it finds, with .rvmrc checked before .ruby-version. A .rvmrc is shell code sourced into your shell, so RVM asks before running it; .ruby-version is plain data.

Run rbenv install 4.0.7 (supplied by the ruby-build plugin) to build Ruby into ~/.rbenv/versions/4.0.7, then rbenv local 4.0.7 in the project to write .ruby-version; rbenv global writes the machine default to ~/.rbenv/version.

rbenv puts ~/.rbenv/shims first on PATH; each shim is a small script that runs rbenv exec, which resolves the selected version and execs that version's executable. rbenv rehash regenerates shims when new executables appear.

rbenv takes RBENV_VERSION first (set by rbenv shell), then the nearest .ruby-version found walking up from the current directory (written by rbenv local), then ~/.rbenv/version (written by rbenv global), and otherwise uses the system Ruby.

rbenv only prepends a shims directory to PATH and resolves the version on each command, without wrapping cd or loading heavy shell functions. It has no gemsets: each installed Ruby has its own gem directory, and Bundler's lockfile isolates each project.

Check that ~/.rbenv/shims comes first on PATH with type -a ruby; usually the rbenv init line sits in a startup file that shell never reads, or a later PATH edit wins. Then run rbenv version to spot a stray RBENV_VERSION.

Map a namespace prefix to a directory under autoload.psr-4, for example "App\": "src/", then require vendor/autoload.php once at the entry point. That file registers Composer's class loader for your code and every dependency, and includes any files entries.

composer install installs the exact versions in composer.lock; composer update re-resolves composer.json's constraints, rewrites composer.lock with the newest allowed versions, then installs. Deploys and CI run install, production with --no-dev; developers run update deliberately.

require lists packages the code needs at runtime, installed everywhere and passed on to the package's consumers. require-dev lists test and tooling packages; it is root-only, so a dependency's dev list is never installed, and --no-dev builds skip it.

dump-autoload -o scans PSR-4 and PSR-0 directories and writes every class into the classmap, so known classes resolve by array lookup, not a filesystem check. It suits production, where code changes only at deploy, not development.

In Composer, ^1.2 and ~1.2 are the same range, >=1.2.0 <2.0.0. They differ with three parts: ~1.2.3 means >=1.2.3 <1.3.0 while ^1.2.3 means >=1.2.3 <2.0.0. For 0.x, ^0.3 means >=0.3.0 <0.4.0.

Packagist is the public package registry Composer queries by default. To publish, push a repository with a valid composer.json named vendor/name, submit its URL on Packagist, and tag releases; Packagist reads versions from tags and branches.

First check whether Packagist re-read the repository, usually a missing hook. Then check whether the tag was skipped for an invalid name, a mismatched version key or missing composer.json. Last, check the consumer's constraint, stability settings and repository order.

Each valid tag becomes a release version, compared without its leading v, with any -beta or -RC suffix setting stability. Each branch becomes a dev version: 2.x becomes 2.x-dev, other names become dev-name, and extra.branch-alias can map dev-main to 1.0.x-dev.

Mark the package abandoned, optionally naming a replacement package, rather than deleting it. Existing versions keep installing, but Composer warns that the package is abandoned and suggests the replacement, and composer audit reports it.

Keep private packages off Packagist.org and serve them from a private repository: individual vcs entries for a few packages, a static registry built with Satis, or a hosted private registry. Credentials go in auth.json or environment variables.