π€ Agentic issue
This was written by Claude (Opus 5), driven by @bjlittle, while investigating an
unrelated CI failure. It is an observation for the core developers to rule on,
not a proposal β I have deliberately not assumed which way you would want to go.
Observation
noxfile.py:189 installs the test-environment dependency nothing straight from
a git default branch, with no ref, tag or commit pin:
session.install("git+https://github.com/SciTools-incubator/nothing.git")
nothing is required by tools/test_release_do_nothing.py, which the tests
session runs (noxfile.py:196). So it is a real dependency of CI, but it appears
in no requirements/*.yml and no requirements/locks/*.lock. It is invisible to
the weekly refresh-lockfiles workflow and to anyone building an environment
from a lock file β pytest tools simply fails at import for them.
The practical consequence is that a push to SciTools-incubator/nothing@main
changes what Iris CI installs, with no commit to this repository. CI could start
failing on every open pull request, and nothing in git log would explain why.
Two details that make it more brittle than it first looks
1. The distribution name collides with an unrelated PyPI package.
SciTools-incubator/nothing declares name = "nothing". There is already a
nothing on PyPI β "a simple package that
does nothing", by Matthias Bussonnier, from
Carreau/nothing. Unrelated project, same
distribution name. The explicit git URL means CI gets the right one today, but
any resolution of nothing by name from an index gets a stranger's package.
2. The version never changes. The git repo has declared version = "0.1"
since it was made installable, has no tags and no releases. pip therefore cannot
distinguish one nothing==0.1 from another β not a newer git HEAD from an older
one, and not the SciTools package from the PyPI one. Anything relying on version
comparison to decide whether to reinstall has nothing to compare.
What this is not
To be clear, because I found this while chasing something else: this did not
cause the recent tests (py3.14) failure on #7276. That was a separate race in
tools/test_release_do_nothing.py under pytest-xdist, and
SciTools-incubator/nothing last changed in March 2026, well before both the
passing and failing runs. I am reporting this because I found it, not because it
has bitten yet.
Options, for you to choose between
- Pin to a commit β
git+https://github.com/SciTools-incubator/nothing.git@df2b356b9.
One-line change, removes the floating behaviour, keeps everything else as is.
Needs a manual bump to take fixes.
- Tag and pin to the tag β same, but gives
nothing a release process.
Needs a decision in the other repository.
- Publish properly β to PyPI or conda-forge under a non-colliding name, and
add it to requirements/*.yml so it flows into the lock files and is visible
to refresh-lockfiles. Most work, but makes pytest tools work for anyone
building from a lock file.
- Accept it β it is a developer-tooling dependency for release scripts, not
a runtime one, and the blast radius is one test module. A reasonable position;
worth recording as a deliberate choice rather than an oversight.
Offer
If it is useful, I am happy to investigate further and raise a pull request for
whichever option you pick β including doing the legwork on option 3 to find out
what publishing would actually involve. Say which, and I will do it. If you would
rather just close this as accepted risk, that is a fine outcome too.
π€ Agentic issue
This was written by Claude (Opus 5), driven by @bjlittle, while investigating an
unrelated CI failure. It is an observation for the core developers to rule on,
not a proposal β I have deliberately not assumed which way you would want to go.
Observation
noxfile.py:189installs the test-environment dependencynothingstraight froma git default branch, with no ref, tag or commit pin:
nothingis required bytools/test_release_do_nothing.py, which thetestssession runs (
noxfile.py:196). So it is a real dependency of CI, but it appearsin no
requirements/*.ymland norequirements/locks/*.lock. It is invisible tothe weekly
refresh-lockfilesworkflow and to anyone building an environmentfrom a lock file β
pytest toolssimply fails at import for them.The practical consequence is that a push to
SciTools-incubator/nothing@mainchanges what Iris CI installs, with no commit to this repository. CI could start
failing on every open pull request, and nothing in
git logwould explain why.Two details that make it more brittle than it first looks
1. The distribution name collides with an unrelated PyPI package.
SciTools-incubator/nothingdeclaresname = "nothing". There is already anothingon PyPI β "a simple package thatdoes nothing", by Matthias Bussonnier, from
Carreau/nothing. Unrelated project, same
distribution name. The explicit git URL means CI gets the right one today, but
any resolution of
nothingby name from an index gets a stranger's package.2. The version never changes. The git repo has declared
version = "0.1"since it was made installable, has no tags and no releases. pip therefore cannot
distinguish one
nothing==0.1from another β not a newer git HEAD from an olderone, and not the SciTools package from the PyPI one. Anything relying on version
comparison to decide whether to reinstall has nothing to compare.
What this is not
To be clear, because I found this while chasing something else: this did not
cause the recent
tests (py3.14)failure on #7276. That was a separate race intools/test_release_do_nothing.pyunderpytest-xdist, andSciTools-incubator/nothinglast changed in March 2026, well before both thepassing and failing runs. I am reporting this because I found it, not because it
has bitten yet.
Options, for you to choose between
git+https://github.com/SciTools-incubator/nothing.git@df2b356b9.One-line change, removes the floating behaviour, keeps everything else as is.
Needs a manual bump to take fixes.
nothinga release process.Needs a decision in the other repository.
add it to
requirements/*.ymlso it flows into the lock files and is visibleto
refresh-lockfiles. Most work, but makespytest toolswork for anyonebuilding from a lock file.
a runtime one, and the blast radius is one test module. A reasonable position;
worth recording as a deliberate choice rather than an oversight.
Offer
If it is useful, I am happy to investigate further and raise a pull request for
whichever option you pick β including doing the legwork on option 3 to find out
what publishing would actually involve. Say which, and I will do it. If you would
rather just close this as accepted risk, that is a fine outcome too.