Change pip default cache path to `**/pyproject.toml`

[flying-sheep]

Description:
requirements.txt is a convention. The only existing standard for where to specify Python dependencies is PEP 621

Related to #502, but not following standards is IMHO a bug, not a missing feature.

Action version:
v4

Platform, Runner type, Tools version:
N/A

Repro steps:
Create a standard Python project, e.g. via hatch new or by following the official tutorial: https://packaging.python.org/en/latest/tutorials/packaging-projects/

Expected behavior:
The default path(s) should end with pyproject.toml.

An option would be to be smart about it and only consider pyproject.toml if it contains a project.dependencies array.

Actual behavior:
The default cache path is **/requirements.txt.

[vsafonkin]

Hi @flying-sheep, we will take a loot at this.

[dmitry-shibanov]

Hello @flying-sheep. The action uses requirements.txt to generate has for primary and restore keys. Do you want to introduce a pyproject.toml file as a fallback if requirements.txt file is missing ?

[flying-sheep]

The only problem with that is that the pure existence of pyproject.toml doesn’t mean the file has PEP 621 dependency metadata (i.e. a project.dependencies array). E.g. some projects configure black in pyproject.toml while also specifying their dependencies in a setup.py or setup.cfg. I think it’s helpful that the action is throwing an error if the default value of cache-dependency-path doesn’t point to a file containing dependencies.

Maybe we change the abstraction to be smarter (or more flexible) than the combination of cache and cache-dependency-path to handle the above?

[dmitry-shibanov]

In this case I think you should specify multiple files in cache-dependency-path. But if you need more complex logic the proper solution would be using the actions/cache to achieve it.

For now I'm going to close the issue.

[flying-sheep]

why? my point is that pyproject.toml is the standard way to specify dependencies in Python.

requirements.txt is not. It’s an old convention.

The default settings should support the standard. Supporting the old convention should be second priority.

[dmitry-shibanov]

In this case we can use my previous suggestion and change logic to use pyproject.toml as fallback if requirements.txt was not found. Moreover, I think a lot of customers still use requirements.txt as a single file for dependencies and it can break builds by removing requirements.txt.

[flying-sheep]

Sure, if that’s how you want to do it.

I think once a standard python lockfile exists, we can get rid of requirements.txt as default (as a major version update of this action). Until then there’s people using both pyproject.toml for abstract dependencies and requirements.txt as a lockfile.

For now I'm going to close the issue.

I’m curious: Why did you do that? This issue is neither fixed nor invalid.

[dmitry-shibanov]

I closed the issue related to your previous comment. As I understood you'd like to introducing changes for parsing both files to get metadata and identify which file should be used for hash. For more complex caching logic it's better to use actions/cache that is why I closed it.

For now I'm going to reopen it.

[Conchylicultor]

+1, actions/setup-python should support the official Python packaging standard (PEP 621 & cie).
At minima, the doc should indicate usage when using pyproject.toml based-dependencies.