Ensure cache supporting files still exist after --cache-clear

[nicoddemus]

Fix #6290

[blueyed]

I've thought about doing it that way also initially, but this still removes e.g. the .git I have there - and I think the idea with the supporting files was to only create them initially (for a new cache base dir), and then do not mess with them, unless the cache root gets created again.
Therefore I think "clearing the cache" should only clear the cache (contents/data), not remove the base directory and everything in it (above the cache data itself).
rm -rf .pytest-cache can be used easily if you want to remove everything really.

[blueyed]

To be clear: this fixes the initial / reported issue, but from my point of view there's another ("it should only remove the cache contents"), which I've tried to address also then in my patch.

[nicoddemus]

I've thought about doing it that way also initially, but this still removes e.g. the .git I have there

Sorry, which .git you mean? The .pytest_cache directory as far as I concerned is owned by pytest, so users shouldn't really be putting custom files/directories there, if that's the case.

it should only remove the cache contents"

I see and it is really not that complicated, but on the other hand I think most people expect --clear-cache to wipe everything (and it is simpler). Plus by doing that we ensure users get updated files when that applies.

As I said, if even with above points you still think we should only wipe d and v directories, I won't discuss further and will update the PR. 😁

[blueyed]

I've thought about doing it that way also initially, but this still removes e.g. the .git I have there

Sorry, which .git you mean? The .pytest_cache directory as far as I concerned is owned by pytest, so users shouldn't really be putting custom files/directories there, if that's the case.

I've put it into a Git repo to e.g. stash last-failed state etc.. IIRC I've posted a script to the mailing-list for this initially. It also helps with debugging/seeing issues with e.g. the lf plugin.

Plus by doing that we ensure users get updated files when that applies.

That's a good point, but it also renoves e.g. a customized .gitignore (imaginary use case probably only).

I'd prefer it to only remove the contents still. But then those could be put into constants / a list maybe (using "d" and "v" is not very descriptive, also where it is used).

[nicoddemus]

I'd prefer it to only remove the contents still.

OK, done. 👍

[blueyed]

👍

[blueyed]

You might want to state this explicitly in the changelog also (the second fix/improvement).