2.13.2: another fix for the conda-forge tests

[joshmoore]

See description in #1143 Testing locally, however, does not suffice. In this case, the relative path in the test worked for me, but doesn't work on conda-forge. The only reliable way to be sure is to run ./build-locally.py in the zarr-feedstock against pre-tagged code. ⚠️

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[codecov]

Codecov Report

Merging #1146 (3803dec) into main (814017d) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1146   +/-   ##
=======================================
  Coverage   99.95%   99.95%           
=======================================
  Files          36       36           
  Lines       14115    14116    +1     
=======================================
+ Hits        14108    14109    +1     
  Misses          7        7           

Impacted Files	Coverage Δ
zarr/tests/test_storage.py	100.00% <100.00%> (ø)

[jakirkham]

Thanks for digging into this Josh! 🙏

Appears the recent feedstock update PR ( conda-forge/zarr-feedstock#67 ) passed 🎉

In terms of testing, my guess is on CI we are relying on being in the source code with the tests, which allows certain simplifying assumptions to work on CI here. Though on conda-forge we are testing the installed package outside the source directory. We could reproduce that environment here on CI with some modest changes if that is of interest

[joshmoore]

I think the options are either add a conda-forge-like / "testing the installed package" GHA or tox configuration here OR adding explicit instructions on what must be done any time anyone touches fixtures/.