galaxyproject / galaxyproject/planemo
Deduplicate planemo.io.wait_on in favor of galaxy.util.wait.wait_on
- 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
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