panoptes / panoptes/panoptes-data

The dependency canary tests the locked tree, not the fresh resolution

Open
#41 0 comments 0 reactions 1 assignee View on GitHub

@wtgee is already working on this.

Since Sep 17, 2026.

cross-repo
Dominant language
Python
Stars
1
Forks
0
Avg merge
18m
Merged PRs (30d)
21

Description

Found while porting this repository's workflows to panoptes-pipeline (panoptes/panoptes-pipeline#226).

canary.yml resolves a fresh dependency tree and then runs the suite:

- name: Resolve dependencies afresh
  run: uv sync --upgrade --group test --python ${{ matrix.python-version }}

- name: Run tests
  run: uv run pytest -q

uv run syncs against the lockfile before running unless told not to. So the second step undoes the first: the fresh resolution is replaced by the pinned tree, and the suite runs against exactly the versions the pull-request jobs already test.

The result is a canary that cannot fail for the reason it exists. It has been green since it was added, which is what you would expect either way -- that is the part that makes this worth fixing rather than noticing later.

Fix
- name: Run tests
  run: uv run --no-sync pytest -q
While in there

Two smaller things in the same file, both about the sync installing more than intended:

  • uv sync --upgrade --group test also installs the default dev group, which includes docs. The canary then resolves and installs zensical and mkdocstrings in order to run pytest. --no-default-groups --group test is what was meant.
  • The same --group / default-group interaction applies to tests.yml and docs.yml, where it costs install time rather than correctness.

See project standards 6.5 in panoptes-pipeline for the written-up version.

Done when

The canary tests the tree it resolved. Worth confirming by reading one run's "Show the resolved tree" output against uv.lock -- if they match, it is still not doing anything.


Filed by Claude Opus 5 · effort: high · 🤖 Claude Code

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.