.gitignore file in cache is created too late
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- PR merge metrics
- PR metrics pending
Description
Bug Report
While mypy is running "infinitely long" (compare #12225), and it's run inside a Git repo, and it's run there for the first time, and the cache location is not set, ..., many cache files (>1900 in my case) are created before any .gitignore file appears. This confuses VS Code quite a bit.
I checked https://github.com/python/mypy/pull/8193/files, and either
- this is related to mypy hanging during metastore creation (in which case it might make sense to create the
.gitignorefile immediately after creating the directory, and not after finishing the store), or - this is related to the cache directory being created in a different piece of code.
The fact that the gitignore file is created after I Ctrl-C the hanging mypy instance makes me think it's 1. So regardless of the root cause of #12225, I wonder if the .gitignore file should be created earlier.
Your Environment
- Mypy version used: 0.942
- Mypy command-line flags: none
- Mypy configuration options from
mypy.ini(and other config files):
check_untyped_defs = true
disallow_incomplete_defs = true
disallow_untyped_calls = true
disallow_untyped_defs = true
show_error_codes = true
- Python version used: 3.10.3
- Operating system and version: Linux
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the cache and .gitignore creation flow with the changes shown in PR #8193, and consider the interaction with the metastore hang described in issue #12225. Reproduce a first run inside a Git repository with no configured cache location, then verify that .gitignore appears before large numbers of cache files are written and that the existing cache behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100