galaxyproject / galaxyproject/planemo

Deduplicate planemo.io.wait_on in favor of galaxy.util.wait.wait_on

Open
#1,680 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
110
Forks
102
Avg merge
4d 21h
Merged PRs (30d)
13

Description

> Posted by Claude (AI assistant) on behalf of the issue author — they did not write this text personally.

`planemo.io.wait_on` (`planemo/io.py:327`) is a near-verbatim duplicate of `galaxy.util.wait.wait_on`. Same algorithm, same docstring phrasing ("Grow the polling interval incrementally by the polling_backoff"). Galaxy's version is the better one and planemo already depends on `galaxy-util`.

### What Galaxy's version adds

- Raises a typed `TimeoutAssertionError(AssertionError)` instead of a bare `Exception`.
- Takes an injectable `sleep_` callable, so waits are testable without real sleeping.
- `delta` is a parameter rather than hardcoded to `0.25`.
- Type annotations.

### Why it should be contained

There are only two callers:

- `planemo/galaxy/config.py:929` — `wait_on(ready, "galaxy tool installation", timeout=DEFAULT_TOOL_INSTALL_TIMEOUT)`
- `planemo/galaxy/activity.py:1027` — `wait_on(get_state, "state", timeout, polling_backoff)`

Both pass `timeout` explicitly, so planemo's `timeout=5` default (Galaxy's is required) doesn't bite. Nothing in `planemo/` or `tests/` catches the timeout or matches on its message, so changing the exception type from `Exception` to `TimeoutAssertionError` shouldn't ripple.

### The one real blocker: the dependency floor

`galaxy.util.wait` does not exist across planemo's whole supported range. It was moved from `galaxy.tool_util.verify.wait` to `galaxy.util.wait` and first ships in **galaxy-util 26.0**. Verified against the published wheels:

| galaxy-util | `galaxy.util.wait` |
| --- | --- |
| 24.1.2 | missing |
| 25.0.1 | missing |
| 26.0.0 | present |
| 26.1.1 | present |

`requirements.txt:10` currently pins `galaxy-util[template]>=24.1,<26.2`, so a resolver is free to pick a version without the module. Doing this dedupe means bumping that floor to `>=26.0`, which is the part worth deciding on deliberately — it may be too aggressive for a release that still wants to support older Galaxy environments. If so, this should wait rather than being worked around with a try/except import.

### Context

Came up while reviewing the postgres/singularity work (#1557, now superseded by #1679). Deliberately *not* proposing to change the polling loop in `planemo/database/postgres_singularity.py` — its `for`/`else` is correct and switching it to `wait_on` would lose the periodic "Waiting for the postgres database to initialize." progress message with no real readability gain.

Same shape as #1467, which dropped planemo's copy of `target_str_to_targets` in favour of the `galaxy.tool_util` one.

Contributor guide

Open the contributing guide

Research direction

Start with planemo/io.py:327, then inspect the two callers in planemo/galaxy/config.py:929 and planemo/galaxy/activity.py:1027. Check requirements.txt:10 and verify the supported galaxy-util versions before deciding whether the dependency floor can move. Done means the compatibility decision is explicit and any deduplication preserves both callers without changing the postgres_singularity polling loop.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Refactor
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.