[WIP] Add GA4GH WES execution path to planemo run#1652
Open
jmchilton wants to merge 2 commits into
Open
Conversation
--wes submits Galaxy workflows to the target Galaxy's WES endpoint instead of the native invocation API. Works for both planemo-managed and external (--galaxy_url) Galaxy servers, reusing the existing Galaxy connection options. Phase 1 scope: workflows only; inputs must be params or data already on the target Galaxy (local file inputs rejected - WES has no staging endpoint). Output download still goes through the native Galaxy API with a warning. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Document WES as a GA4GH compatibility checkbox; native execute is more functional/performant. - Drop dead workflow-type detection (Galaxy ignores workflow_type for gxworkflow:// refs); use a constant placeholder. - Reuse io.wait_on for WES polling (add back-compatible interval kwarg); remove hand-rolled loop. - Stop conflating WES state with Galaxy invocation_state: leave Galaxy states untracked, surface wes_state separately in invocation details. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
[WIP] — opening early for visibility; not ready for merge.
What
Adds a
--wesflag toplanemo runthat submits Galaxy workflows to the target Galaxy's GA4GH WES endpoint instead of the native invocation API.--wesis a modifier on the Galaxy execution path, not a separate engine — it reuses the existing Galaxy connection options and targets whichever server you're already pointing at (planemo-managed, or external via--galaxy_url).Phase 1 scope
WES has no data-staging or output-download endpoint, so initial support is intentionally limited:
{"src": "hda", "id": ...}). Local file inputs (class: Filewithpath/location) are rejected.--download_outputsstill works but downloads via the native Galaxy API (with a warning), since WES defines no download mechanism.Run success is derived from the terminal WES state.
Changes
planemo/galaxy/wes.py— thinrequests-only WES client (submit run, poll to terminal state) + state helpers.planemo/galaxy/activity.py—wes_execute/_wes_execute, param validation, polling, andWesRunResponse.planemo/engine/galaxy.py— route towes_executewhen--wesis set.planemo/commands/cmd_run.py—--wesvalidation (Galaxy workflows + galaxy/external_galaxy engines only).planemo/options.py—wes_option.docs/_running_external.rst— usage docs.tests/test_wes.py— client + plumbing tests.🤖 Generated with Claude Code