Skip to content

Day 4 #2: Rails worker auto-pins generated project to local ruby#11

Closed
dadachi wants to merge 1 commit intomainfrom
feat/day4-ruby-version-pin
Closed

Day 4 #2: Rails worker auto-pins generated project to local ruby#11
dadachi wants to merge 1 commit intomainfrom
feat/day4-ruby-version-pin

Conversation

@dadachi
Copy link
Copy Markdown
Contributor

@dadachi dadachi commented Apr 21, 2026

Summary

Resolves the second Day-4 finding: substrate pins ruby "4.0.2", user's local mise had 4.0.1, bundle install on the generated project hard-failed until the pin was manually relaxed.

After this PR, the rails worker:

  1. Detects the locally-installed ruby via ruby -e "print RUBY_VERSION" (exec subprocess, no shell).
  2. Reads the generated project's .ruby-version.
  3. If they differ, rewrites .ruby-version and any literal ruby "X.Y.Z" line in the Gemfile to match local.
  4. Logs the action via the rails trace so it's visible in tmux.
  5. If ruby isn't on PATH at all, skips the rewrite silently — Day-5 Layer-2 will surface the missing-ruby error with fuller context.

Why both files (defensive)

The substrate's Gemfile uses ruby file: ".ruby-version" — reads dynamically from the file — so updating .ruby-version alone is enough in practice. The Gemfile-literal regex remains as a defensive no-op for substrates that hard-code ruby "X.Y.Z" directly.

Verified

Trace output from clinic-queue run on this machine (local ruby 4.0.1, substrate pin 4.0.2):

[rails] scanned 305 files, changed 142, 2546 substitutions, 49 file/dir renames
[rails] pinned ruby 4.0.2 -> 4.0.1 (local)
[rails] done (out/clinic-queue/rails)

bundle install on the generated project now succeeds out-of-the-box (no manual .ruby-version edit needed). bin/rails test on that generated project continues to hit 405/0/0 as of PR #9's probe.

Test plan

  • npm run ci — 5/5 green
  • Generated clinic-queue rails has .ruby-version = 4.0.1 (match local)
  • bundle install succeeds out of the box
  • Generated project with matching ruby version: no rewrite, "already matches" trace line (not retested, covered by code path if (pinned === localVersion) return;)

Substrate pins ruby 4.0.2; user's machine may have a nearby version
(e.g. 4.0.1 via mise). Pre-fix, `bundle install` on the generated
project hard-failed until the user manually relaxed the pin. Now
the rails worker detects the locally-installed ruby (via
`ruby -e "print RUBY_VERSION"`) and rewrites .ruby-version + any
literal `ruby "X.Y.Z"` in Gemfile to match.

Substrate's Gemfile actually uses `ruby file: ".ruby-version"`, so
rewriting .ruby-version alone is enough in practice; the Gemfile
regex remains as a defensive no-op for substrates that hard-code.

If ruby isn't on PATH at all, skip the pin rewrite and let Day 5
Layer 2 surface the missing-ruby error.

Verified: generated clinic-queue rails pins to 4.0.1, bundle
install succeeds out of the box without manual edits.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@dadachi
Copy link
Copy Markdown
Contributor Author

dadachi commented Apr 21, 2026

Closed: finding is obsolete since the user's mise has the pinned Ruby 4.0.2 installed. The generated project's .ruby-version will auto-switch correctly when Layer 2 runs bundle install in out//rails. Auto-relaxation was overreach.

@dadachi dadachi closed this Apr 21, 2026
@dadachi dadachi deleted the feat/day4-ruby-version-pin branch April 21, 2026 11:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant