mypy check fails in hpi config check: FileNotFoundError

[jussihuotari]

Does hpi config check work in a virtual environment? I get an error when running hpi config check or checking a module, e.g. hpi doctor my.hypothesis:

» hpi config check                       
✅ import order: ['/Users/jussi/me/hpi/my']
✅ config file : /Users/jussi/me/hpi.config/my/config/__init__.py
✅ syntax check: /Users/jussi/me/hpi/bin/python3.9 -m compileall /Users/jhu/projects/mememo/hpi.config/my/config/__init__.py
❌ mypy check: failed
   Traceback (most recent call last):
     File "/usr/local/Cellar/python@3.9/3.9.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
...
...
   FileNotFoundError: [Errno 2] No such file or directory: '.mypy_cache/3.9/my/config/__init__.data.json'

I think this is not a mypy error because running mypy directly works:

» MYPYPATH=../hpi.config mypy --namespace-packages -p my.config 
Success: no issues found in 1 source file

I suspect the issue is related to how mypy is ran using subprocess.run():
https://github.com/karlicoss/HPI/blob/master/my/core/__main__.py#L47

Maybe this method changes the current working directory unlike running mypy directly on command line?

If I patch my.core.__main__ to print the directory just before the failing run(), it points to a temp directory (I'm on a MacOS, using venv for HPI):

    print("My path", os.path.abspath(".mypy_cache"))
    # My path /private/var/folders/j0/bc42cwsn7b59s623gyrtywsw0000gn/T/hpi_temp_dir/.mypy_cache

The mentioned .../hpi_temp_dir/.mypy_cache/... exists but the erroring file __init__.data.json is not found there. Instead, such file is in the console's current working dir, under the .mypy_cache/... path.

Does hpi config check work in a virtual environment?

This issue doesn't prevent usage. Also, feel free to close this issue if you think this doesn't belong here (but maybe on https://github.com/python/mypy/issues). However, I like the HPI's idea of being able to check the configuration programmatically. It's a cool feature especially for new users trying to set up the (cool) framework.

[purarue]

hmm -- looks like there is code to check if we can use the current python env, so I think it was meant to work....

This may be because of the change to a temporary directory, you can see the reasoning for that here, It has been there since before click was used for it -- reasoning being to prevent accidental imports from relative files while developing since how hpi handles imports is already confusing enough

Does this work if you remove this block of code and replace it with a pass?

Also, you've probably already tried this, but does this work if you invoke with python3 -m my.core instead of hpi? Though, the virtualenv should probably be placing the virtualenvs bin directory in front of where any global hpi could be installed anyways, may be a moot point.

[jussihuotari]

Excellent pointers, thank you. I was going to try the code removal you referred to, but... now that I tried the erroring command in the same virtual env, it works. hpi config check-> success!

I haven't changed much in my venv or the config. I have added a custom HPI module and played with automated scripts with hpi query, and added a class core: block in the HPI config file. So... I guess the issue must have been some caching problem in mypy (the other hard thing in CS). Closing the issue.