diff options
| author | Sergey Vlasov <sigprof@gmail.com> | 2023-11-21 18:05:29 +0300 | 
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-11-21 15:05:29 +0000 | 
| commit | 7e27d72cbc9af11b5de3f0c30810a0b95267acee (patch) | |
| tree | 881b9617096ed411f13a69660f11638ab6567829 /tmk_core/protocol/host_driver.h | |
| parent | 68722d35a3e7c0bd32eccf7da8ddddc6de7e2e57 (diff) | |
Fix `qmk find` failure due to circular imports (#22523)
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.
Diffstat (limited to 'tmk_core/protocol/host_driver.h')
0 files changed, 0 insertions, 0 deletions
