Repository navigation
.pytest_cache is showing up in projects git repos #3286
Description
Activity
Not sure how this would be actionable for pytest?
its not clear to me either, but i started to note that people are affected by our change in a negative unintended way
Reacted by György Kiss and Saida DiperiPeople probably made the same mistake when we introduced
pytest-cacheinto the core and hence.cachestarted to be created every time pytest executed.I see that
.pytest_cachealready made into GitHub's default.gitignorefile in github/gitignore@f651f0d, which is good.Reacted by Gunther Cox@nicoddemus that doesnt help people updating their projects however
Indeed it does not, just thought I would mention that.
One thing that might help is to add a
.pytest_cache/READMEfile which explains what is the purpose of the directory and that it should not be added to version control. Of course few people will actually read that file, but other than that I'm out of ideas on how to improve the situation.TBH I don't consider this critical, certainly a nuisance but not critical.
- added 2 commits that reference this issue
on Apr 9, 2018 18 remaining items
We use Mercurial for example, so adding .gitignore would not really work in our case
Good point, we should also add Mercurial and other systems (Bazaar, ?)
Does anybody see any drawback with having a
.gitignore(and etc) with mask*in there? Seems like the perfect solution, solves the problem and trivial to implement.git is the de facto winner of the scm wars due to the network effects - so lets add it, and be open for users of other systems to add support for their scm's
Hmm I agree. When I suggested to support other systems, I was under the impression that the most popular ones work similarly to
.gitignore, as I have seen.hgignoremultiple times. But reading the documentation I found you can only have a single.hgignorenext to.hg, so this greatly complicates things. Same with Bazaar.It is very hard to solve this issue for every SCM (except changing the location of
.pytest_cacheas depicted in #1089), so better to fix this with a simple solution for Git users rather than not solve this for everyone and linger this forever.We can always change the solution later if we find a better way, after all.
- added 2 commits that reference this issue
on Sep 24, 2018 - added a commit that references this issue
on Sep 24, 2018 - added a commit that references this issue
on Oct 1, 2018 - added 2 commits that reference this issue
on Oct 23, 2018 - added a commit that references this issue
on Jan 7, 2019
i just noted that this started to happen, as far as i can tell the .cache rename was a breaking change for users