Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Agentic] Test dependency nothing is installed unpinned from a git default branchΒ #7277

Description

@bjlittle

πŸ€– 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

  1. 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.
  2. Tag and pin to the tag β€” same, but gives nothing a release process.
    Needs a decision in the other repository.
  3. 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.
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions