Ruby

1. What's in the catalogue

Three published lines — 3.3.12, 3.4.10, 4.0.6 — pin with the full version (kapsl [email protected]); minor forms like @4.0 resolve too. As of catalogue 2026.35.22 (2026-08-25):

No declared-not-published Ruby entries. No rubocop, no rake line, no rspec in the catalogue either — see Tooling for what that means in practice.

2. The five-minute version

kapsl ruby --version
ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [aarch64-linux]

Run a script:

kapsl ruby app.rb

The Gemfile-based form — bundle install against your Gemfile, into a scanned environment image, then the script:

kapsl -e @gem:Gemfile ruby app.rb

The gem provider is auto-detected by filename: in a directory with a Gemfile, kapsl -e . ruby app.rb picks up the gem provider with no explicit @gem: — the explicit spelling above is how a project pins it. The environment is the unit of caching, as for every other provider — Gemfile.lock is the companion file that makes the build reproducible.

3. The environment story: the system gem directory

Unlike Composer (per-project ./vendor by convention), Ruby's install model is global: bundle install writes to the system gem directory, and require finds gems there without any per-project wiring. The provider leans on exactly that — gems install into the environment image's gem directory, and the run container needs no BUNDLE_PATH or RUBYLIB tricks. Your working tree stays clean; the dependency set lives in the scanned image.

Gems with native extensions (nokogiri, bigdecimal, the usual suspects) work out of the box: the build runs with gcc/make apt-installed live against the composed Ruby image, so the compile step succeeds inside the environment build. The ruby-gemfile example's colorize happens to be pure Ruby; the README documents the native path and why no extra configuration is needed.

4. Tooling

No Ruby linter or test runner is in the catalogue: no rubocop, no rspec, no rake line. Until one publishes, linting is the IDE use case's territory, and rake-driven test suites run through the environment itself (kapsl -e @gem:Gemfile ruby -S rake test) or through a project overlay that grants what the suite needs.

5. Project patterns

• ruby-simple — the no-dependency shape at all three levels: bare kapsl ruby, a minimal .kapslrc, and the shim.
• ruby-gemfile — a Gemfile project: bundle install into the environment, native-extension support, and the system-gem-directory rationale above.

The second one is the whole pattern in five lines:

kapsl -e @gem:Gemfile ruby app.rb

6. Known limitations

• The catalogue side is thin. This is the honest state of the page: one tool, one provider, no linters. A project that wants rubocop either runs it through a local [tools] mapping of its own (see Tool mappings) or waits for a published line.
• Lockfile discipline is on you. The environment build is reproducible only as far as Gemfile.lock is; a Gemfile without a committed lock resolves fresh on every build, and a version bump rebuilds and rescans the environment image.