Repository navigation
TST/DEP: replace pytest-astropy with corresponding, direct dependencies #18783
Description
Part of #18782
Started at #18780
The problem is two-fold:
- requiring the
pytest-astropymetapackage instead of the corresponding, direct requirements, means we don't have direct control over the lower bounds of our direct dependencies. pytest-astropycurrently requires a superset of our actual test requirements. Notably, this means we still pullpytest-openfilesfrom PyPI on every single test run, even though we don't use it, and it's explicitly marked as unsupported.
Reacted by Nick Murphy
Reacted by P. L. Lim
Activity
oldestdeps#18782pllim commentedon Oct 28, 2025
As you found out over at #18784 , pytest-astropy is more than just a meta-package.
https://github.com/astropy/pytest-astropy/blob/main/pytest_astropy/plugin.py
neutrinoceros commentedon Oct 28, 2025
indeed. But that plugin is less than 50 lines of code, so I'm willing to experiment with (re)including it in
astropy's own test suite.pllim commentedon Oct 28, 2025
That.... might be controversial. We cannot remove it from pytest-astropy and we cannot archive pytest-astropy. So your proposal would amount to duplicating code that we have to keep maintaining on both sides.
neutrinoceros commentedon Oct 28, 2025
Yes. I expect controversy, but I also don't see any better solution to the problems I'm trying to solve (other than lock files, which, as we've seen, are not any less controversial)
eerovaher commentedon Nov 5, 2025
As a metapackage
pytest-astropybecame obsolete when we started declaring our dependencies using self-referential dependency sets in 98710e2. The markerspytest-astropyplugin defines are useful, but they are not specific toastropy, sopytest-astropyis not the package that should be implementing them.astrofrog commentedon Apr 27, 2026
@neutrinoceros - what if we were to split out the plugin from pytest-astropy into its own mini-package to avoid duplication since other packages might want to do the same as what we are doing here? Making a small package is easy enough these days and pytest-astropy would then become a pure metapackage we can just drop.
neutrinoceros commentedon Apr 28, 2026
Yeah, that'd be my preferred solution
neutrinoceros commentedon May 26, 2026
In researching this, I found
@pytest.mark.slowcan already be replaced bypytest-skip-slow. The only difference is the corresponding CLI flag,--slowinstead of--run-slow, but we could easily propose an alias for backward compat. I note the repo hasn't been active in 3 years but the project is also extremely simple so it's not necessarily a show stopper, and we could probably offer to host and maintain it if that helps reaching a decision.@pytest.mark.hugememdoesn't have a clear replacement yet, though it could probably fit inpytest-skip-slow's scope too. I'll to reach out to Brian to see what he says regardless.neutrinoceros commentedon May 26, 2026
Had a quick chat with @okken, and he's on board with the idea. I'll open a couple PRs tomorrow, so as to facilitate migration.
neutrinoceros commentedon May 27, 2026
pytest-skip-slow 1.1.0 is out (thank you @okken !) and confirmed to be the minimal, drop-in replacement I was aiming for. I'll ask the rest of the team about this proposal on the mailing list.