On Tue, Sep 22, 2020 at 05:00:27PM -0400, John Snow wrote: > All of the QAPI include statements are changed to be package-aware, as > explicit relative imports. > > A quirk of Python packages is that the name of the package exists only > *outside* of the package. This means that to a module inside of the qapi > folder, there is inherently no such thing as the "qapi" package. The > reason these imports work is because the "qapi" package exists in the > context of the caller -- the execution shim, where sys.path includes a > directory that has a 'qapi' folder in it. > > When we write "from qapi import sibling", we are NOT referencing the folder > 'qapi', but rather "any package named qapi in sys.path". If you should > so happen to have a 'qapi' package in your path, it will use *that* > package. > > When we write "from .sibling import foo", we always reference explicitly > our sibling module; guaranteeing consistency in *where* we are importing > these modules from. > > This can be useful when working with virtual environments and packages > in development mode. In development mode, a package is installed as a > series of symlinks that forwards to your same source files. The problem > arises because code quality checkers will follow "import qapi.x" to the > "installed" version instead of the sibling file and -- even though they > are the same file -- they have different module paths, and this causes > cyclic import problems, false positive type mismatch errors, and more. > > It can also be useful when dealing with hierarchical packages, e.g. if > we allow qemu.core.qmp, qemu.qapi.parser, etc. > > Signed-off-by: John Snow <js...@redhat.com>
Here's the answer to the question I sent on patch 03/38. :) Reviewed-by: Eduardo Habkost <ehabk...@redhat.com> -- Eduardo
