Day 4 #2: Rails worker auto-pins generated project to local ruby#11
Closed
Day 4 #2: Rails worker auto-pins generated project to local ruby#11
Conversation
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>
Contributor
Author
|
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves the second Day-4 finding: substrate pins
ruby "4.0.2", user's local mise had 4.0.1,bundle installon the generated project hard-failed until the pin was manually relaxed.After this PR, the rails worker:
ruby -e "print RUBY_VERSION"(exec subprocess, no shell)..ruby-version..ruby-versionand any literalruby "X.Y.Z"line in the Gemfile to match local.Why both files (defensive)
The substrate's Gemfile uses
ruby file: ".ruby-version"— reads dynamically from the file — so updating.ruby-versionalone is enough in practice. The Gemfile-literal regex remains as a defensive no-op for substrates that hard-coderuby "X.Y.Z"directly.Verified
Trace output from clinic-queue run on this machine (local ruby 4.0.1, substrate pin 4.0.2):
bundle installon the generated project now succeeds out-of-the-box (no manual.ruby-versionedit needed).bin/rails teston that generated project continues to hit 405/0/0 as of PR #9's probe.Test plan
npm run ci— 5/5 green.ruby-version = 4.0.1(match local)bundle installsucceeds out of the boxif (pinned === localVersion) return;)