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

Update uv.lock + CI tweaks + fix pymatgen issue #6676

Merged
merged 10 commits into from
Jan 8, 2025

Conversation

danielhollas
Copy link
Collaborator

@danielhollas danielhollas commented Dec 29, 2024

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)

I had an issue with scipy, needed to be 1.14.1 for the python 3.13 but uv lock and uv lock --upgrade did not upgrade even though my local version was 1.14.1, then with uv lock --upgrade-package scipy==1.14.1 it finally told me that it does not upgrade because scipy==1.14.1 does not support python 3.9. So I needed to specify the scipy version for the python 3.13 separately.

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.

Copy link

codecov bot commented Dec 29, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.94%. Comparing base (02cbe0c) to head (79c81a7).
Report is 1 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

@danielhollas
Copy link
Collaborator Author

danielhollas commented Dec 30, 2024

There's one failing test in test-install with Python 3.9, due to astral-sh/setup-uv#219

        # In Cygwin paths like "c:\..." and '\cygdrive\c\...' are possible
>       if p_venv.parts[1] == "cygdrive":
E       IndexError: tuple index out of range

.venv/lib/python3.9/site-packages/IPython/core/interactiveshell.py:890: IndexError
========================================================== slowest 50 durations ===========================================================

(3 durations < 1s hidden.  Use -vv to show these durations.)
========================================================= short test summary info =========================================================
FAILED tests/tools/ipython/test_ipython_magics.py::test_ipython_magics - IndexError: tuple index out of range

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.

@danielhollas danielhollas changed the title WIP: Update uv.lock + CI tweaks Update uv.lock + CI tweaks Jan 7, 2025
@danielhollas danielhollas marked this pull request as ready for review January 7, 2025 12:42
@danielhollas danielhollas changed the title Update uv.lock + CI tweaks Update uv.lock + CI tweaks + fix pymatgen issue Jan 7, 2025
@danielhollas
Copy link
Collaborator Author

@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:

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.

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
Copy link
Collaborator Author

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 :-( )

Copy link
Contributor

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.

Copy link
Member

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 }}
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Copy link
Contributor

@agoscinski agoscinski left a 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
Copy link
Contributor

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.

Copy link
Member

@unkcpz unkcpz left a 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
Copy link
Member

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.

@agoscinski
Copy link
Contributor

Thanks for the work @danielhollas this was really helpful!

@unkcpz unkcpz merged commit 1093026 into aiidateam:main Jan 8, 2025
22 checks passed
@unkcpz
Copy link
Member

unkcpz commented Jan 8, 2025

Thanks @danielhollas I merge it to not block other PRs on going.

@danielhollas danielhollas deleted the update-lock branch January 8, 2025 16:35
@edan-bainglass
Copy link
Member

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?

@danielhollas
Copy link
Collaborator Author

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.

@unkcpz
Copy link
Member

unkcpz commented Feb 8, 2025

However, aiida-quantumespresso builds still failing. Can you comment on this briefly?

The CI seems all passed in aiida-quantumespresso. Which one you mean?

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.

5 participants