(chore): derive CI matrix from hatch env

[ilan-gold]

• Just like (chore): derive CI matrix from hatch env scanpy#3607
• Tests added
• Release note added (or unnecessary)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.07%. Comparing base (2e9cfca) to head (a618a86).
⚠️ Report is 39 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1998      +/-   ##
==========================================
- Coverage   87.10%   85.07%   -2.03%     
==========================================
  Files          46       46              
  Lines        6949     6949              
==========================================
- Hits         6053     5912     -141     
- Misses        896     1037     +141     

see 7 files with indirect coverage changes

[flying-sheep]

Ah, I just realized: Since we do

hatch run ${{ matrix.env.name }}:run

Instead of hatch test, hatch won’t do its CLI argument processing, so --randomize and --parallel don’t exist, and the normal defaults of the plugins apply.

E.g. when we do hatch test without --randomize, hatch passes -p no:randomly to the CLI to disable the plugin. Doing hatch run hatch-test.*:run means that we’re already using the plugin in scanpy (and this PR).

[ilan-gold]

Doing hatch run hatch-test.*:run means that we’re already using the plugin in scanpy (and this PR).

Why did I have to add the PYTEST_ADDOPTS then?

[ilan-gold]

I don't think we need an equivalent of scverse/scanpy#3607 (comment) here. If the case arises where we have non-experimental extras, then we can revisit. But xarray is both experimental and likely to be removed in the enxt released in a standalone package. I foresee a scenario where we support array libraries in the future, but in that case I would just make a new arr-full section or similar.

[ilan-gold]

Re: testing for coverage, I would be in favor of doing it for each type here. pre, min, and stable could in theory have three different behaviors (unlikely) in which case we would want full coverage.

[flying-sheep]

sure, why not! would make things simpler too. The reason we had it this way is as you said; it’s very unlikely to have three branches.

/edit: done

Why did I have to add the PYTEST_ADDOPTS then?

because while we have a coverage and non-coverage version of the test step, they both had shared options: -n auto --junitxml=... and so on

I don't think we need [a minimal extra features job]

OK. I think then the min, stable, and pre triad also makes sense as names, as min is not ambiguous between “few/no extra features” and “resolve to lowest possible dependency versions”.

[flying-sheep]

looks good, but why are the tests so slow? (that’s not new, I just saw it now)

before you merge, please edit the rules in https://github.com/scverse/anndata/settings/rules

1. In both rulesets (version branch and default branch)
2. go to “Require status checks to pass” → “Show additional settings” → “Status checks that are required”
3. remove all pytest (…) entries
4. remove the check-build entry
5. add the check entry instead
6. save
7. refresh this PR page to see that you can now merge with a green button

[ilan-gold]

looks good, but why are the tests so slow? (that’s not new, I just saw it now)

I would assume it's the xarray tests + zarr v3/v2 both being tested, both of which ballooned the tests here by quite a bit. Another reason to remove the xarray part of the codebase. I can also look into perhaps doing some more reuse of fixtures or cutting down on number of tests.

[flying-sheep]

oof, this should have stayed in.