__pycache__ directory containing .pyc files shadows some pyscript modules causing errors and persistently returns after deletion

[dorbitbrown]

Recently, some of my pyscript modules started failing with odd errors like, "NameError: name 'input_text' is not defined", and the same for "input_boolean", "log" and other magic HA or pyscript features, exactly as if the modules were in /pyscript_modules/ rather than in /pyscript/modules. Finally I noticed a pycache folder in /pyscript/modules, containing .pyc files for exactly the modules that were failing. I realized they were running plain Python, and causing the .py files to be shadowed and not run by the pyscript async interpreter. So, the solution seemed easy--delete them. BUT, a few seconds after deleting, the directory and files mysteriously and persistently reappeared again.

Is there some hidden flag or list that I can modify to stop this from happening?

[craigbarratt]

pyscript shouldn't create a compiled cache directory. Is there any chance some instance of regular python is executing scripts in that directory?

[dorbitbrown]

Thanks for the rapid reply, Craig! I checked out a bunch of dead ends. Following are findings that seem relevant. See second-to-last paragraph for a possible lead:

It turns out the .pyc files are being generated by Python on the Raspberry Pi, since they are all .cpython-312.pyc, while my PC's Python is 3.11. I confirmed by running a /pyscript_modules/ test file from VSCode; it generated a .cpython-311.pyc file.

I'm running HA OS, so have nothing fancy going on.

I tired copying and renaming the affected files as a workaround, just to get my system running again. However, new .pyc files got created for them, too! Creating blank .py files and copying in the code had the same problem.

This started happening around the time I started to migrate a module from /pyscript/modules into /pyscript_modules/, but ended up moving it back. It seems more than coincidental that the affected modules are it and any that it directly or indirectly imports. Scripts and modules which import it are unaffected. Can you think of a way that could that have caused this?

Anything further you suggest I investigate?

[dorbitbrown]

I just ran a test which confirms it is Pyscript creating the __pycache__ directory and the .pyc file. I used the fact that Pyscript considers files whose name starts with "#" to be disabled, while normal Python does not. Let's call the file at issue bad_mod.py, and the module which imports it importer.py. Then the process I followed was:

1. Disabled importer.py by renaming it #importer.py
2. Deleted the __pycache__ directory and wait five minutes during which the __pycacyhe__ directory did not reappear.
3. Renamed #importer.py as importer.py thereby re-enabling it, and noted the time it was saved.
4. Soon after, __pycache__ reappeared, and the timestamp on its bad_mod.cpython-312.pyc file matched the time at which importer.py was re-enabled.