fix: pip cache failures in workflows

[xarvex]

From #255:

Ocassionally, a pip install will fail because of mismatched hashes, which from my research I believe this to be related to a cache error. This cannot easily be tested due to its seemingly random nature, but my hope is that my fix in using the action/setup-python workflow will avoid it.

Unfortunately the fix in 82037e5 seems to have just caused registered bad cache to be reused over and over. So, this serves as a sort of "opposite" to that and removes using the cache altogether.

Again, due to random nature, this cannot easily be tested and will show results over time.

[yedpodtrzitko]

This is most likely caused by requirements-dev.txt which is not taken into account when creating the cache key, only requirements.txt is considered by default.

This can be fixed by specifying cache-dependency-path

I'm not sure if this wouldn't exclude requirements.txt for a change:

cache-dependency-path: '**/requirements-dev.txt'

so using this should be safe:

cache-dependency-path: '**/requirements*.txt'

[xarvex]

This is most likely caused by requirements-dev.txt which is not taken into account when creating the cache key, only requirements.txt is considered by default.

This can be fixed by specifying cache-dependency-path

I'm not sure if this wouldn't exclude requirements.txt for a change:

cache-dependency-path: '**/requirements-dev.txt'

so using this should be safe:

cache-dependency-path: '**/requirements*.txt'

I would think this if it weren't for the fact that packages in requirements.txt are affected by this too, and actually happens with only those packages as far as I have been able to tell. For example, the release workflow which only uses requirements.txt experienced this error recently.

[yedpodtrzitko]

So this means the error happens during download, which means the problem isnt in the cached files. I tried to search for the error message, and it seems pip doesnt know the connection was interrupted, considering the download is complete which causes the hash mismatch.

In that case not using cache wont help, it might make the problem worse as we'll be downloading each dependency every time, increasing the chance for the mismatch.

Is there any occurrence of this problem for the pytest workflow? In that one there's upgrade to latest version of pip (python -m pip install --upgrade pip) which we can hope has the problem fixed.

Other than that I found that uv has also dealt with this problem, but they actually fixed it ( astral-sh/uv#1912 ), so using uv instead of pip could be worth trying:

pip install uv
uv pip install -r requirements.txt

[xarvex]

Going back to the drawing board for this.

[yedpodtrzitko]

this was most likely fixed within #332 by using uv and I havent experienced any errors, so we can close this:

TagStudio/.github/workflows/pytest.yaml

Lines 39 to 43 in fb949b8

	- name: Install dependencies
	run: |
	python -m pip install --upgrade uv
	uv pip install --system -r requirements.txt
	uv pip install --system -r requirements-dev.txt