forked from forks/qmk_firmware
7e27d72cbc
There was an import cycle in the Python modules:
- `qmk.build_targets` imported `qmk.cli.generate.compilation_database`;
- importing `qmk.cli.generate.compilation_database` requires
initializing `qmk.cli` first;
- the initialization of `qmk.cli` imported the modules for all CLI
commands;
- `qmk.cli.compile` imported `qmk.build_targets`.
This cycle did not matter in most cases, because `qmk.cli` was imported
first, and in that case importing `qmk.cli.generate.compilation_database`
did not trigger the initialization of `qmk.cli` again. However, there was
one corner case when `qmk.bulld_targets` was getting imported first:
- The `qmk find` command uses the `multiprocessing` module.
- The `multiprocessing` module uses the `spawn` start method on macOS
and Windows.
- When the `spawn` method is used, the child processes initialize
without any Python modules loaded, and the required modules are loaded
on demand by the `pickle` module when receiving the serialized objects
from the main process.
The result was that the `qmk find` command did not work properly on macOS
(and probably Windows too); it reported exceptions like this:
ImportError: cannot import name 'KeyboardKeymapBuildTarget' from partially initialized module 'qmk.build_targets' (most likely due to a circular import)
Moving the offending `qmk.cli.generate.compilation_database` import into
the method which actually uses it fixes the problem.
|
||
|---|---|---|
| .. | ||
| cli | ||
| tests | ||
| __init__.py | ||
| build_targets.py | ||
| c_parse.py | ||
| commands.py | ||
| comment_remover.py | ||
| constants.py | ||
| converter.py | ||
| datetime.py | ||
| decorators.py | ||
| errors.py | ||
| flashers.py | ||
| git.py | ||
| importers.py | ||
| info.py | ||
| json_encoders.py | ||
| json_schema.py | ||
| keyboard.py | ||
| keycodes.py | ||
| keymap.py | ||
| makefile.py | ||
| math.py | ||
| painter.py | ||
| painter_qff.py | ||
| painter_qgf.py | ||
| path.py | ||
| search.py | ||
| submodules.py | ||
| util.py | ||