GitHub Actions: Simplify requirements cache

[cclauss]

Type of Changes

	Type
✓	🐛 Bug fix

Description

Why recreate a venv and keep reactivating that venv at each job step when actions/setup-python already automatically does so?

Why keep dependencies in both pyproject.toml and multiple requirements_*.txt files which make cache key calculation complex?

Remove the complex cache gymnastics to see if pytests can pass on PyPy 3.11.

Refs #XXXX

Closes #10287
Closes #10286

The one failing pytest on PyPy3.9 and PyPy3.10 seems to be a full path vs. partial path difference.

- Using config file /opt/hostedtoolcache/PyPy/3.9.19/x64/lib/pypy3.9/site-packages/pylint/testutils/testing_pylintrc
+ Using config file pylint/testutils/testing_pylintrc

Which is minor but the 48 other failing pytests on PyPy3.11 seem to require attention.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.86%. Comparing base (a3e5bef) to head (73f17d0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10288   +/-   ##
=======================================
  Coverage   95.86%   95.86%           
=======================================
  Files         175      175           
  Lines       19074    19074           
=======================================
  Hits        18286    18286           
  Misses        788      788           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Pierre-Sassoulas]

Let's separate pypy3.10 fix / caching changes / pypy 3.11 support. I can see the former being merged relatively fast but 49 failing tests is going to take a while (and afaik no maintainer is using pypy).

[mbyrnepr2]

The cache logic changes look a great improvement but do you need to explicitly switch on the caching for pip?

Supported package managers are pip, pipenv and poetry. The cache input is optional, and caching is turned off by default.

https://github.com/actions/setup-python?tab=readme-ov-file#caching-packages-dependencies

[cclauss]

I find the blending of requirements in pyproject.toml AND in multiple requirements_*.txt files to be quite confusing but perhaps all the combinations and permutations of add-ons and plugins make that necessary. I will create a different PR to try to use matrix.os to reduce the complexity of .github/workflows/tests.yaml before I circle back to this one.

• GitHub Actions: Simplify tests using matrix.os #10299

[Pierre-Sassoulas]

I find the blending of requirements in pyproject.toml AND in multiple requirements_*.txt files to be quite confusing but perhaps all the combinations and permutations of add-ons and plugins make that necessary.

afair it's a choice we did because someone preferred to be able to have requirements.txt 2/3 years ago. Personally I add an extra called dev / test in the pyproject.toml and remove requirements.txt (but it does create an extra on pypi that no one is supposed to use). If you have a proposal that is better / simpler than what we currently have I'm open to it.

[Julfried]

PEP 735 defines dependency groups, which do extactly what Pierre suggested here, without having to create extras in pyproject.toml. This will also be supported in the upcoming pip release: pypa/pip#13065. Other package managers, like uv already support it

[cclauss]

For me, the confusion comes in here

pylint/requirements_test.txt

Line 1 in f98805e

-r requirements_test_min.txt

and

pylint/requirements_test_min.txt

Line 1 in f98805e

.[testutils,spelling]

where requirements.txt files can import other requirements files and even optional-dependencies from pyproject.toml.

I guess we will need to use dependency groups that specify all dependencies that they need.

[Julfried]

PEP 735 dependency groups are intended to be self-contained lists of dependencies, so one group cannot automatically include extras from another (e.g. using .[testutils, spelling]). I believe this kind of composition isn’t possible with dependency groups, though I'm not entirely sure. Before implementing any changes, it would be wise to wait until this feature is officially released in pip.

[cclauss]

Or stop using pip and use uv instead.

[Julfried]

While I am also a fan of uv, I do not think that forcing everyone to use it is the way to go here. Moving the github actions to uv makes sense though to improve speed.

[Pierre-Sassoulas]

Agree with @Julfried here, we should not force uv on every potential contributor, let's wait for pip support for that and the github action can use uv in the meantime.

[Pierre-Sassoulas]

Another thing though is that we're caching pylint editable install and we should not (it makes the doc generation and config file exemple generation checks fail unexpectedly)

[DanielNoord]

Other idea: what if we run this new setup in parallel and check if it fixes all caching issues? Then we don't need to worry about porting everything and stuff potentially breaking. We can just make it a non required workflow and migrate once we deem it to be finished.

[cclauss]

astral-sh/setup-uv@v5 is not allowed to be used in pylint-dev/pylint. Actions in this workflow must be: within a repository owned by pylint-dev, created by GitHub, or matching the following: codecov/codecov-action@, kanga333/comment-hider@, pypa/gh-action-pip-audit@, pypa/gh-action-pypi-publish@, sigstore/gh-action-sigstore-python@, softprops/action-gh-release@, tibdex/backport@*.

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit e6e4048

[Julfried]

Other idea: what if we run this new setup in parallel and check if it fixes all caching issues? Then we don't need to worry about porting everything and stuff potentially breaking. We can just make it a non required workflow and migrate once we deem it to be finished.

I would agree here. Also I think we should first add dependency groups to pyproject.toml, so that people who use uv can use them and newly added actions aswell. Once they work properly and pip officially supports them remove all the requirements.txt files.

[cclauss]

I think you folks have a clearer idea of what you want than I do, so please create the required PRs.