-
Notifications
You must be signed in to change notification settings - Fork 219
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
Update uv.lock + CI tweaks + fix pymatgen issue #6676
Conversation
34bffbf
to
8e66b24
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6676 +/- ##
=======================================
Coverage 77.94% 77.94%
=======================================
Files 563 563
Lines 41761 41761
=======================================
Hits 32545 32545
Misses 9216 9216 ☔ View full report in Codecov by Sentry. |
8e66b24
to
475cedb
Compare
There's one failing test in test-install with Python 3.9, due to astral-sh/setup-uv#219
EDIT: This was now resolved upstream, but was not release yet. I've added a workaround in the meantime so we can move in with this PR. |
568639a
to
77f1481
Compare
77f1481
to
86938af
Compare
@unkcpz @agoscinski this is now ready for review, please take a look, I've written an extended PR description, let me know if anything is not clear. Note in particular:
Regardless if we decide if this is a good solution or not, I think this PR should go in first before #6680 since it fixes the pymatgen issue for everything except Python 3.9. |
|
||
- name: Install dependencies from uv lock | ||
if: ${{ inputs.from-lock == 'true' }} | ||
# NOTE: We're asserting that the lockfile is up to date | ||
# NOTE2: 'pre-commit' extra recursively contains other extras | ||
# needed to run the tests. | ||
run: uv sync --locked --extra pre-commit |
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.
Previously we were not respecting the inputs.extras
when using the lockfile. Now we do (at the expense of very ugly Github Actions syntax :-( )
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.
I think it is inspired from JavaScript so at least not completely random.
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.
in CI will inputs.extras
in uv sync --locked ${{ inputs.extras && format('--extra {0}', inputs.extras) || '' }}
always be true
? Because if it is not pass as input it will set to "pre-commit" as default, no? Then this clause can be simplified.
Never mind, I see extra='' below.
shell: bash | ||
|
||
- name: Install aiida-core | ||
if: ${{ inputs.from-lock != 'true' }} | ||
run: uv pip install --system -e .${{ inputs.extras }} |
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.
Since now setup-uv
action activates the virtual environment automatically, we no longer need to install into system python.
run: uv run pytest -n auto --db-backend psql -m 'not nightly' tests/ ${{ matrix.python-version == '3.9' && '--cov aiida' || '' }} | ||
# NOTE2: Unset CI envvar to workaround a pymatgen issue for Python 3.9 | ||
# https://github.com/materialsproject/pymatgen/issues/4243 | ||
# TODO: Remove a workaround for VIRTUAL_ENV once the setup-uv action is updated |
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.
This issue is described in detail in #6676 (comment).
I'll remove the workaround hopefully soon in a subsequent PR.
|
||
- name: Install utils/ dependencies | ||
run: uv pip install --system -r utils/requirements.txt | ||
|
||
- name: Validate uv lockfile | ||
run: uv lock --locked | ||
run: uv lock --check |
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.
The --check
option is a new alias for --locked
which is more intuitive.
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.
Looks good to me, just need some clarifications with some changes
|
||
- name: Install dependencies from uv lock | ||
if: ${{ inputs.from-lock == 'true' }} | ||
# NOTE: We're asserting that the lockfile is up to date | ||
# NOTE2: 'pre-commit' extra recursively contains other extras | ||
# needed to run the tests. | ||
run: uv sync --locked --extra pre-commit |
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.
I think it is inspired from JavaScript so at least not completely random.
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.
In the new uv version, this is not the case, and uv will try to find the newest version of a package for a given python version.
This is nice!
It looks good, thanks @danielholla Just a small question.
|
||
- name: Install dependencies from uv lock | ||
if: ${{ inputs.from-lock == 'true' }} | ||
# NOTE: We're asserting that the lockfile is up to date | ||
# NOTE2: 'pre-commit' extra recursively contains other extras | ||
# needed to run the tests. | ||
run: uv sync --locked --extra pre-commit |
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.
in CI will inputs.extras
in uv sync --locked ${{ inputs.extras && format('--extra {0}', inputs.extras) || '' }}
always be true
? Because if it is not pass as input it will set to "pre-commit" as default, no? Then this clause can be simplified.
Never mind, I see extra='' below.
Thanks for the work @danielhollas this was really helpful! |
Thanks @danielhollas I merge it to not block other PRs on going. |
Hi @unkcpz. Didn't follow this discussion, but I see that it was merged. However, aiida-quantumespresso builds still failing. Can you comment on this briefly? |
What is the error? I don't think changes in this PR would influence aiida-qe since it doesn't use the uv.lock file. I think the original pymatgen issue is solved by simply bumping the pymatgen version. |
The CI seems all passed in aiida-quantumespresso. Which one you mean? |
I've recreated the uv lockfile (
uv.lock
) with a newer uv version that uses an updated resolution strategy, which in particular solves an issue reported by @agoscinski in #6640 (comment)uv produces a "universal" lockfile for all python versions that we support, i.e >=3.9.
Previously, it tried to find a version of the package that would be compatible with all supported Python versions, which in turn meant that if a package dropped support for 3.9 for example, we'd be stuck on an old version.
In the new uv version, this is not the case, and uv will try to find the newest version of a package for a given python version.
Incidentally, this also help partly resolve the pymatgen issue, see #6680. The issue has been fixed in a new version of
monty
package, which however does not support Python 3.9. So in the updated lockfile, the issue is fixed for Python >=3.10.For Python 3.9, I added a workaround suggested in materialsproject/pymatgen#4243 (comment), and unset the CI environmental variable.
Since this woraround is quite targeted (only in two specific job steps, and only for Python 3.9), I believe this is acceptable, and we will be dropping Python 3.9 support sometimes this year anyway.