Repository navigation
Conversation
`specify preset resolve` looked at command and template artifacts only, so a preset that registers an executable artifact as `type: script` (e.g. a .mjs adapter) was reported as not found even though the resolver stack holds it. Keep the current precedence (commands for dotted names, templates otherwise) and fall back to the script type before reporting not found. The resolved path is the same top-layer path the command already prints for templates. Adds a regression test that registers a preset with a `type: script` entry and asserts the CLI resolves it; the test fails on main and passes with the change.
There was a problem hiding this comment.
🟡 Changes recommended
The CLI tests lack regression coverage confirming that a template takes precedence over a same-named script from a higher-priority preset.
1 open issue
What changed in this PR
This PR addresses #4819 by letting Specify CLI resolve preset script artifacts without changing existing command or template precedence.
Changes:
- Adds script fallback for non-dotted names when no template layers exist.
- Updates CLI help and not-found wording to include scripts.
- Adds a regression test for resolving an installed
.mjsscript.
The PR reports before-and-after regression evidence; tests were not rerun during this review.
AI-assisted review for the requester (identity unavailable) by GitHub Copilot; model unknown, automated review mode. Repository inspection and review wording were AI-generated.
| File | Description |
|---|---|
tests/specify_cli/presets/test_command_resolve.py |
Adds script-only CLI resolution regression coverage. |
src/specify_cli/presets/command_resolve.py |
Adds script fallback and updates user-facing descriptions. |
Review effort: Balanced (auto)
The script fallback must keep the backward-compatible lookup order: a template resolves even when a same-named script lives in a higher-priority preset. Covers the negative case requested in review.
There was a problem hiding this comment.
🟡 Changes recommended
The new fixture gives the template higher priority than the script, so the test would pass even if resolution incorrectly used cross-type priority rather than type-first precedence.
2 open issues
Review effort: Balanced (auto)
mnriem
added
the
triage-can-wait
… test PresetRegistry.list_by_priority() sorts ascending, so the lower number is the higher priority. With the template at priority 5 it already outranked the script at 20, which meant the test passed even for a script-first implementation. Swap them: the script now has priority 5, the template 20. Verified the test fails against a script-first lookup and passes with the template-first order.
Fixes #4819.
What
specify preset resolve <name>now falls back to thescriptartifact type before reporting "not found".scriptlayers. Presets may register executable artifacts astype: script(e.g.adapters/page-adapter.mjs), and the resolver stack already holds them — only the CLI never asked for that type.Evidence
A regression test was added in
tests/specify_cli/presets/test_command_resolve.py:On
main(before the change) it fails, reporting the exact symptom from the issue:With the change it passes and prints the installed
page-adapter.mjspath.The whole presets suite passes:
801 passed, 1 skipped.Scope
One concern: the CLI lookup only. The resolver's Python-level
resolve(name, "script")/resolve_content(name, "script")behaviour, manifest handling and composition are untouched.AI disclosure
Implemented with an AI coding agent (OpenCode) using DeepSeek V4.1 Flash, human-supervised; the fix, the regression test and this description were generated by the agent and reviewed by the contributor before submission.