Skip to content

Add shed-tools validate subcommand#237

Open
jmchilton wants to merge 3 commits into
masterfrom
tools_yaml_validate
Open

Add shed-tools validate subcommand#237
jmchilton wants to merge 3 commits into
masterfrom
tools_yaml_validate

Conversation

@jmchilton

@jmchilton jmchilton commented Jun 12, 2026

Copy link
Copy Markdown
Member

Drafted by Claude (AI assistant) on behalf of @jmchilton.

What

Adds a shed-tools validate subcommand: no-install, no-Galaxy validation of a tools file / .yml.lock against a Tool Shed. Closes #236.

  • Structural check reuses the RepositoryInstallTargets pydantic model via read_tools (same parsing as install).
  • Shed check asserts each repository exists and every pinned revision is installable, querying each repo once.
  • --structural-only skips all network access — suitable for offline pre-commit / CI on revision-pinned lock files.
  • The subcommand needs no Galaxy connection; it deliberately does not inherit the Galaxy connection args.
shed-tools validate tools.yml                 # structure + shed
shed-tools validate tools.yml --structural-only   # offline, no network

Hardening (second commit)

  • extra=forbid on RepositoryInstallTarget(s) so a typo'd key (e.g. revision: for revisions:) fails structurally instead of silently passing with the pin unchecked — the failure mode the validator exists to catch. Safe: the install path reads raw YAML and does not use the model; the only model consumers are validate, the IDC generator (known keys only), and tests.
  • read_tools rejects a non-mapping / empty YAML root with a clear error instead of a TypeError from **-splatting None.

Tests

tests/test_shed_tools_validate.py fakes the Tool Shed via monkeypatch (no network): structural-only good/bad, full good/bad-revision, missing file, no input, unknown-key rejection, empty/non-mapping root, query-once-per-repo. mypy clean.

Comment cleanup (rolled in from #238)

Per @mvdbeek's review on #238, the first commit tidies two comments that landed with that merge: drops the run-data-managers comment wrongly claiming Galaxy 26.0 requires a history to execute tools (the real cause was a session without an associated history), and trims the verbose galaxy-app pin comment in dev-requirements.txt.

🤖 Generated with Claude Code

jmchilton and others added 3 commits June 14, 2026 15:05
Drop the run-data-managers comment claiming Galaxy 26.0 requires a history to
execute tools (it doesn't; the failure was a session without an associated
history), and trim the verbose galaxy-app pin comment in dev-requirements.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
No-install, no-Galaxy validation of tools files / .yml.lock against a Tool
Shed. Structural check reuses RepositoryInstallTargets/read_tools; shed check
asserts each repo exists and every pinned changeset_revision is installable.
--structural-only skips network for offline pre-commit. Closes #236.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
extra=forbid on RepositoryInstallTarget(s) so a typo'd key (e.g. revision
vs revisions) fails structurally instead of silently passing with the pin
unchecked. read_tools now rejects a non-mapping/empty YAML root with a clear
error instead of a TypeError from **-splatting None; validate() catches it.

Install path is unaffected (reads raw YAML, not the model).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@jmchilton jmchilton force-pushed the tools_yaml_validate branch from bc5b0b6 to 21e87bb Compare June 14, 2026 19:11
@bgruening

Copy link
Copy Markdown
Member

@arash77 this looks interesting. Can you please point John to the scripts that you have been cooking - removing the non-installable revisions etc? Maybe that is interesting for whatever @jmchilton is cooking here.

@arash77

arash77 commented Jun 15, 2026

Copy link
Copy Markdown
Member

Sure! You can find the scripts for filtering out the non-installable tool revisions in this PR: usegalaxy-eu/usegalaxy-eu-tools#929

@arash77

arash77 commented Jun 15, 2026

Copy link
Copy Markdown
Member

Should we also allow/validate the top-level install_tool_dependencies , install_repository_dependencies , and install_resolver_dependencies keys?
Currently, shed-tools validate fails on files that define these defaults because RepositoryInstallTargets uses extra=Extra.forbid but doesn't declare them.

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.

Add a way to validate a tools.yaml against a Tool Shed without installing

3 participants