-
-
Notifications
You must be signed in to change notification settings - Fork 443
Simplify constraints configuration #7642
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
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7642 +/- ##
==========================================
- Coverage 92.87% 92.86% -0.02%
==========================================
Files 630 630
Lines 58995 59205 +210
==========================================
+ Hits 54791 54979 +188
- Misses 4204 4226 +22 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks @Czaki. +1 for simplifying complexity in CI config.
@Czaki, can you explain what this changes a little bit more? Is the goal to not have to parse a separate set of constraints for windows? If so, isn't part of the goal of the constraints to get the correct PyQt5 version? I have found that even with the constraints sometimes installing on Windows goes a bit sideways with both pip and conda, and often some type of pyqt-related package gets the wrong version grabbed. Will that fix this, or potentially make the problem worse? If there is a way I can help test what this changes, please let me know. Or are constraints just for CI? (haven't totally figured this stuff out yet, since I'm used to things being declared in pyproject) |
@TimMonko There are three changes here.
Could you elaborate more? At first, constraints are designed for pure pip (or uv) installation. And in such a situation I do not know how with constraints, the wrong version of Qt may be picked.
The main target of constraints is to stabilize CI. For example, some package release may break our tests. Without constraints, such release break development of all actively developed PR. With constraints, the PRs are untouched, and we could fix problems in constraints PR or report a bug to upstream and mark the version as broken. Moreover, the user may use constraints to install napari in a tested version of requirements. I expect that it may be mainly useful for someone who would like to install older napari version. But I do not expect that lack of pinning of PyQt5 may be problematic, but maybe you have another experience. PyQt5 maintainer wrote this on mailing list:
|
6e2c962
to
6ed146e
Compare
I think, partly, I'm misunderstanding constraints usage. But also, realizing that in many of the bad solves they are on undergraduate's devices; I'm guessing they are running into having previous installs on their device, like in #7646 . Then, it works for them only in some python versions but not others, due to conflicts of what/how they installed for classes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about copy the explanation post to the OP?
I found it very helpful, maybe future code archeologists might as well?
Whole or only part? Could You edit the description to add missed information? |
@Czaki @psobolewskiPhD @TimMonko @jni I love the teamwork on this PR. Great job sharing knowledge about changes. 💯 |
Description
There are three changes here.
napari/resources/constraints/constraints_py3.10.txt(
napari/resources/constraints/constraints_py3.10.txt
Line 2 in 39b385d
could be easier executed locally as there will be no napari_repo in the path. That will allow to easier recalculate constraints locally.
With these changes, it will be easier to run update of constraints locally.