✨ Detect engine-incompatible dev dependencies (Phase 4) - #64
Open
pboling wants to merge 38 commits into
Open
Conversation
Implements Phase 4 of GEMSPEC_DEV_DEPENDENCY_PLAN.md (case 3: a direct
development dependency that doesn't support one or more of the
destination's declared engines and has no template-managed modular
home — sqlite3 on jruby is the pilot). Unlike case 1
(modular_dependency_conflicts), there's no modular-side declaration to
match against, so this needed its own detection function rather than
reusing that one.
- Add #engine_dependency_conflicts: compares each direct dependency's
KNOWN_GEM_CONFLICT_RESOLUTIONS :engine_incompatible#supported_engines
against the destination's declared engines (config["engines"],
falling back to DEFAULT_ENGINES via #enabled_ruby_engines). Uses a
fixed, human-readable :modular placeholder ("(engine-incompatible;
no modular home)") instead of a real file path, so a decision stays
matched across runs even if the destination's declared engines
change without resolving the incompatibility.
- Factor the direct-dependency-path glob (Gemfile + gemspecs, on disk
or pending in this run's recipe reports) out of
#modular_dependency_conflicts into #direct_dependency_paths, shared
by both detection functions.
- Wire #engine_dependency_conflicts into
#validate_modular_dependency_conflicts! alongside the existing
modular-conflict detection; both funnel into the same
dependency_conflicts.resolve list, decision-matching, and review
gate.
- Broaden #auto_resolvable_known_gem_conflict? (new
AUTO_RESOLVABLE_KNOWN_GEM_CONFLICT_CATEGORIES constant) to also
accept :engine_incompatible, so a future registry entry in this
category with force_review: false can auto-resolve the same way
:template_managed does today. sqlite3's force_review: true means
this doesn't change its own behavior; it always surfaces for review.
- Update now-stale comments referencing "Phase 4" as not-yet-existing.
New specs in template_bootstrap_spec.rb: surfaces a review placeholder
for sqlite3 (jruby unsupported), does not flag it when declared
engines are all ruby, and raises on a second run when the surfaced
conflict is still unreviewed — mirroring the existing case-1 coverage.
Verified: spec/integration/template_bootstrap_spec.rb 51/51 and the
full suite 683/683 under
STRUCTUREDMERGE_DEV=<path-to-ruby/gems> (0 failures, better than this
plan's own documented 673/677 baseline — those 4 were pre-existing
environment artifacts, apparently since fixed elsewhere). rubocop-gradual
clean.
Remaining from GEMSPEC_DEV_DEPENDENCY_PLAN.md Phase 4: P4.4 (apply to
active_security and activerecord-transactionable, resolve via review)
is a destination-repo change, not a kettle-jem change — tracked
separately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01URwq1vEg3L7F3ddUr5eEn4
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
1 participant
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.
Implements Phase 4 of
GEMSPEC_DEV_DEPENDENCY_PLAN.md(case 3: a directdevelopment dependency that doesn't support one or more of the destination's
declared
engines:and has no template-managed modular home —sqlite3onjrubyis the pilot).#engine_dependency_conflictsdetection function (case 1'smodular_dependency_conflictscan't see this: there's no modular-sidedeclaration to match against for a gem below the template's inclusion
threshold).
#direct_dependency_paths.#validate_modular_dependency_conflicts!alongside the existingdetection — same
dependency_conflicts.resolvelist, decision-matching,and review gate.
#auto_resolvable_known_gem_conflict?so a future:engine_incompatibleregistry entry withforce_review: falsecanauto-resolve the same way
:template_manageddoes today.sqlite3'sforce_review: trueis unchanged — it always surfaces for review.kettle-jem-template-20260913-001) and thisrepo's own
CHANGELOG.md.New specs in
template_bootstrap_spec.rbmirror the existing case-1coverage: surfaces a review placeholder, doesn't flag when declared engines
are all supported, raises on a second run when still unreviewed.
Verified: focused spec 51/51, full suite 683/683 under
STRUCTUREDMERGE_DEV=<path-to-ruby/gems>(0 failures — better than thisplan's own documented 673/677 baseline; those 4 were pre-existing
environment artifacts).
rubocop-gradualclean.Remaining from the plan's Phase 4: P4.4 (apply to
active_securityandactiverecord-transactionable, resolve via review) is a destination-repochange, tracked separately.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
🤖 Generated with Claude Code
https://claude.ai/code/session_01URwq1vEg3L7F3ddUr5eEn4