TST/DEP: set direct requirements on test dependencies with accurate lower bounds by neutrinoceros · Pull Request #18780 · astropy/astropy

neutrinoceros · 2025-10-25T14:56:24Z

Description

Problem: mindeps testing still runs on the latest version of hypothesis, because it isn't already declared as a direct dependency (instead we rely on the meta-package pytest-astropy to provide it), and we resolve this test env with --resolution=lowest-direct (I'm actively working on moving to --resolution=lowest but this will take some work upstream and time).
Other test dependencies that we only pull in via pytest-astropy might also create issues but hypothesis is the one blocker I'm having right now in my trials for --resolution=lowest, because it emits a warning (for which I'm adding a filter here) at collection time.

partially address #18783

By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

github-actions · 2025-10-25T14:56:42Z

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

Do the proposed changes actually accomplish desired goals?
Do the proposed changes follow the Astropy coding guidelines?
Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

github-actions · 2025-10-25T14:56:42Z

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

neutrinoceros · 2025-10-25T15:03:31Z

actually I already figured out some other safe minimal requirements from pytest-astropy in my inquiries so might as well include them too

neutrinoceros · 2025-10-25T17:19:21Z

This should be stable now. I still want to revisit and see if we actually use everything that got pulled from pytest-astropy. Otherwise I'll use constraints rather than requirements.

pllim · 2025-10-28T01:21:02Z

pyproject.toml

 # The base set of test-time dependencies.
 test = [
    "coverage>=6.4.4",
+    "hypothesis>=6.84.0",


Why not just put 6.142.4 here? No point forcing an older version and then have to ignore a bunch of warning.

The problem is that we still get warnings with much more recent versions of hypothesis in the conditions I'm trying to resolve for (--resolution=lowest), so I must conclude that they are a side effect of some other, transitive dependencies that I haven't been able to identify just yet.

pllim · 2025-10-28T01:21:47Z

pyproject.toml

+    'ignore:_SixMetaPathImporter\.find_spec\(\) not found; falling back to find_module\(\):ImportWarning', # from hypothesis
+    'ignore:_SixMetaPathImporter\.exec_module\(\) not found; falling back to load_module\(\):ImportWarning', # from prompt-toolkit
+    "ignore:distutils Version classes are deprecated. Use packaging.version instead.:DeprecationWarning",
+    "ignore: module 'sre_constants' is deprecated:DeprecationWarning", # from matplotlib 3.6.0 via pyparsing 3.0.0


Hmm. Why not pin older matplotlib to older pyparsing?

we already set a lower bound for matplotlib (3.6.0), which itself has a lower bound for pyparsing, but it points to a version that didn't have wheels for Python 3.11.
We could in principle set our own lower bound on pyparsing via a constraint (not a requirement), but then we'd need to keep it in sync with whatever our current lowest supported versions for Python and matplotlib are. My current solution (exclude building pyparsing from source + ignore deprecation selected warnings) should be at least somewhat easier to maintain, as we don't need to rediscover an oldest working version manually each time we upgrade Python or mpl, but any new warning needing filters will be glaring. The cost is that we might accumulate a couple outdated, unused warning filters with time, but that seems benign to me (and we can always clean them up on our own schedule).

I thought the whole point of this exercise is to have compatible lower bounds of deps, no?

Indeed. But we don't have exact control over the majority of our dependencies that are only transitive, nor should we attempt to. We can however instruct the resolver to avoid wasteful builds. Does this make sense ?

I am not super happy we have to start ignoring random warnings again just because of the new way we do oldest deps, but I would like to hear from other devs as well. Thanks for tackling this! Dependencies are hard to navigate in Python.

(FWIW I just ran resolution=lowest tests with matplotlib>=3.6 as a constraint on top of everything included here except the warning filters and I didn't observe any improvement)

"ignore: module 'sre_constants' is deprecated:DeprecationWarning", # from matplotlib 3.6.0 via pyparsing 3.0.0

Oh yes, well, I'm mostly concerned about collection-time warnings now, as they are completely blocking. Maybe we could move forward with this one first and then drop support for mpl 3.6 in a follow up PR ?

I think I have a better idea still: the reason for treating warnings as errors is that we want to know when something about our env changes or is about to change. This reason goes away if we get reproducible envs, which is the end goal here. So how about we merge this with the filters, but I also open a subissue for #18783 as reminder that

we can let warnings be warnings in oldestdeps

we can remove all filters introduced in this PR once we're there

how does this sound ?

I opened and linked #18853

hope that satisfies everyone

neutrinoceros · 2025-11-10T17:16:00Z

rebased to resolve a merge conflict.
FWIW, I believe this is the last piece I need before I can resolve #18783

…ower bounds

…ild in CI

neutrinoceros · 2025-11-12T18:46:16Z

superseded by #18896 and #18897

neutrinoceros added this to the v7.2.0 milestone Oct 25, 2025

neutrinoceros added no-changelog-entry-needed dev-automation dependencies Pull requests that update a dependency file testing labels Oct 25, 2025

github-actions bot added the installation label Oct 25, 2025

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from b97a493 to 15ff4e7 Compare October 25, 2025 15:02

neutrinoceros changed the title ~~TST/DEP: set a direct requirement on hypothesis with an accurate lower bound~~ TST/DEP: set direct requirements on test dependencies with accurate lower bounds Oct 25, 2025

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch 2 times, most recently from 3b79e71 to 3c84aa0 Compare October 25, 2025 17:17

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from fe27911 to b9b956d Compare October 25, 2025 18:51

neutrinoceros marked this pull request as ready for review October 25, 2025 19:14

This was referenced Oct 26, 2025

TST: towards reproducible builds for oldestdeps #18782

Closed

TST/DEP: replace pytest-astropy with corresponding, direct dependencies #18783

Open

TST/DEP: drop pytest-astropy in favor of corresponding, direct test dependencies #18784

Draft

pllim reviewed Oct 28, 2025

View reviewed changes

astrofrog modified the milestones: v7.2.0, v8.0.0 Nov 3, 2025

neutrinoceros requested a review from eerovaher November 5, 2025 19:53

neutrinoceros mentioned this pull request Nov 5, 2025

TST/DEP: bump minimal requirement on pytest-xdist (2.5.0 -> 3.6.0) #18838

Merged

1 task

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from b9b956d to 88f1cf7 Compare November 8, 2025 15:33

neutrinoceros mentioned this pull request Nov 8, 2025

TST: stop treating warnings as errors in oldestdeps CI #18853

Closed

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from a1c12c5 to a211b58 Compare November 10, 2025 17:12

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from a211b58 to 081027a Compare November 10, 2025 17:40

neutrinoceros added 4 commits November 12, 2025 08:55

TST/DEP: set direct requirements on test dependencies with accurate l…

3cdfb73

…ower bounds

TST: add missing warning filters

ecb285b

TST/DEP: add contourpy and pillow to the list of packages to never bu…

bba4514

…ild in CI

MNT: link follow up issue

68005a8

neutrinoceros force-pushed the tst/dep/set-direct-requirement-on-hypothesis branch from 081027a to 68005a8 Compare November 12, 2025 07:55

This was referenced Nov 12, 2025

TST/DEP: bump minimal requirement on pytest-astropy to 0.11.0 #18896

Merged

TST/DEP: add contourpy and pillow to the list of package we never want to build #18897

Merged

neutrinoceros closed this Nov 12, 2025

neutrinoceros deleted the tst/dep/set-direct-requirement-on-hypothesis branch November 12, 2025 18:46

Uh oh!

Conversation

neutrinoceros commented Oct 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

github-actions bot commented Oct 25, 2025

Uh oh!

github-actions bot commented Oct 25, 2025

Uh oh!

neutrinoceros commented Oct 25, 2025

Uh oh!

neutrinoceros commented Oct 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neutrinoceros commented Nov 10, 2025

Uh oh!

neutrinoceros commented Nov 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

neutrinoceros commented Oct 25, 2025 •

edited

Loading