Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: test minimum stated dependencies on CI with uv --resolution lowest-direct #109

Merged
merged 54 commits into from
Feb 11, 2025

Conversation

tlambert03
Copy link
Member

@tlambert03 tlambert03 commented Jan 18, 2025

This PR is trying to make our tests a little more robust. I think the ultimate underlying cause has to do with retaining strong references to various qt objects, which is preventing proper cleanup. But the goal here isn't immediately to fix that. Rather, this establishes patterns for using uv to quickly test many different environment configurations locally (and also uses that same setup on CI). There is a guide in CONTRIBUTING.md that should explain most of it.

The key takeaway is that one can easily get setup here just running uv sync. And then you can test any combo of extras with make test extras=vispy,pyqt [min=1] [isolated=1] [py=3.10] (brackets are optional features)

The massive 6000+ line change here is due to the uv.lock file, which will be checked into source (makes it very easy to get reproducible dev environments with uv sync). I've also gone through and re-evaluated all of our minimum dependency pins, and test those as well on CI.

For now, I've added a few "retries", that should minimize test failures due to segfaults. but i hope to remove these in the future after digging into the segfaults.

@gselzer, have a quick look and let me know if any of this would cramp your style. I know make isn't a builtin command on windows, but i believe it can be installed (alternatively we can use just ... but that also needs to be installed)

Copy link

codecov bot commented Jan 18, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.81%. Comparing base (17dd5c1) to head (ffa1b58).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #109      +/-   ##
==========================================
+ Coverage   76.41%   76.81%   +0.40%     
==========================================
  Files          49       49              
  Lines        4956     4930      -26     
==========================================
  Hits         3787     3787              
+ Misses       1169     1143      -26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tlambert03
Copy link
Member Author

woohoo! all green checks without re-running! :)

@tlambert03
Copy link
Member Author

tlambert03 commented Feb 11, 2025

sorry to bug @gselzer, would love to have our tests green again :) this isn't as big of a change as it looks from the line count.

the biggest change for you is that it moves dev dependencies into dependency-groups https://peps.python.org/pep-0735/ ... which does actually mean you can't do pip install -e .[dev] anymore, because pip doesn't yet supported those. I personally don't use pip anymore (always use uv) and would love to have those deps in the proper section, and enable simple uv sync. But, if your muscle memory would be too cramped by not being able to pip install -e .[dev], or if you have other general questions, let me know!

Copy link
Collaborator

@gselzer gselzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry to bug @gselzer, would love to have our tests green again :) this isn't as big of a change as it looks from the line count.

D'oh! Sorry I missed this.

You're utilizing many tools that I am not terribly familiar with, so I have no real suggestions for you, however I think this is a great step forward, and I'm excited to gain more exposure to uv!

One small concern that I have, looking back at the tests, is that ndv is hogging public (read: GitHub) resources. We have 40+ tests, each averaging a minute or more. Since that isn't really an effect of these changes (though re-running the tests will exacerbate the problem), that shouldn't hold up merging. Maybe I'll file a few issues.

@@ -387,7 +387,7 @@ def _generate_clim_positions(self, npoints: int = 256) -> np.ndarray:
Y[2:-2] = np.linspace(0, 1, npoints) ** self._gamma
np.array([(np.mean(clims), 2**-self._gamma)])

return np.vstack((X, Y, Z), dtype=np.float32).transpose()
return np.vstack((X, Y, Z)).astype(np.float32).transpose()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious why you made this change - did it fix tests, or help performance?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixes the minimum stated numpy version

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! So it is...thanks for enlightening me!

...although, I think it's funny that you bumped NumPy from 1.22 to 1.23 in this PR, and 1.24 is the version introducing np.vstack's dtype parameter 😆

@tlambert03
Copy link
Member Author

tlambert03 commented Feb 11, 2025

One small concern that I have, looking back at the tests, is that ndv is hogging public (read: GitHub) resources. We have 40+ tests, each averaging a minute or more.

are you concerned for github on the whole? :) resources are restricted on an organization basis, so they don't let you use more than a certain amount at a time. that's why they don't all run immediately (you'll see them queue). can you clarify the key concern here?

edit: I can definitely merge different parts of the matrix into a single job, but then our tests will take longer.

@gselzer
Copy link
Collaborator

gselzer commented Feb 11, 2025

are you concerned for github on the whole? :) resources are restricted on an organization basis, so they don't let you use more than a certain amount at a time. that's why they don't all run immediately (you'll see them queue). can you clarify the key concern here?

"Key concern" sounds strong 😅

Ideally, we'd uncover the issues causing our segfaults and remove the repeated runs. That's the main thing I wouldn't mind having an issue tracking.

edit: I can definitely merge different parts of the matrix into a single job, but then our tests will take longer.

Well, I wouldn't change anything here. I don't want to merge jobs either, because flat > nested!

@tlambert03
Copy link
Member Author

tlambert03 commented Feb 11, 2025

remove the repeated runs.

ah... ok, well the good news here is that most of them aren't repeated... For example, most look like this

Screenshot 2025-02-11 at 6 47 21 PM

(i.e. it only repeats if it fails, preventing me from having to manually go in and press "repeat failed tests").

occasionally we see this, where only the third test actually passed (attempt 3 must pass or it fails the test)

Screenshot 2025-02-11 at 6 48 15 PM

I think having this in will help me repeat this locally much easier, because I can quickly test with various environments with a single make command

@tlambert03
Copy link
Member Author

ok thanks for having a look. Apologies if it causes any difficulty in local setup, and we can always add back a dev extra if you'd like. just let me know

@tlambert03 tlambert03 merged commit 5b404bf into pyapp-kit:main Feb 11, 2025
52 checks passed
@tlambert03 tlambert03 deleted the uv-tests branch February 11, 2025 23:51
@gselzer
Copy link
Collaborator

gselzer commented Feb 11, 2025

I think having this in will help me repeat this locally much easier, because I can quickly test with various environments with a single make command

Absolutely! I'd just hope that we will eventually solve the segfaults instead of "hiding" them behind repeated runs.

Apologies if it causes any difficulty in local setup, and we can always add back a dev extra if you'd like. just let me know

Should be fine, I think I'll survive!

@tlambert03
Copy link
Member Author

I'd just hope that we will eventually solve the segfaults instead of "hiding" them behind repeated runs

don't worry, that's absolutely the goal. the problem is mostly pyside, and it almost entirely happens on CI, so it's A) not affecting users much and B) hard to debug. This just lets us at least keep moving on other stuff as long as it's not fundamentally all broken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants