Enable absolute imports in lldbsuite. Absolute imports were introduced in Python 2.5 as a feature (e.g. from __future__ import absolute_import), and made default in Python 3. When absolute imports are enabled, the import system changes in a couple of ways: 1) The `import foo` syntax will *only* search sys.path. If `foo` isn't in sys.path, it won't be found. Period. Without absolute imports, the import system will also search the same directory that the importing file resides in, so that you can easily import from the same folder. 2) From inside a package, you can use a dot syntax to refer to higher levels of the current package. For example, if you are in the package lldbsuite.test.utility, then ..foo refers to lldbsuite.test.foo. You can use this notation with the `from X import Y` syntax to write intra-package references. For example, using the previous locationa s a starting point, writing `from ..support import seven` would import lldbsuite.support.seven Since this is now the default behavior in Python 3, this means that importing from the same directory with `import foo` *no longer works*. As a result, the only way to have portable code is to force absolute imports for all versions of Python. See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more information about absolute and relative imports.
Details
Diff Detail
Event Timeline
Does this mean that if we import third party modules, and since you have embedded them into our package, that we would have to change third party code to adhere to our packaging structure? If not, fine. If so, this was one of the areas I mentioned that I was concerned about with the monolithic packaging structure.
No. I actually explicitly went out of my way to remove the third party packages from our package. That's why they are all in lldb/third_party now. use_lldb_suite adds all the third_party directories to sys.path up front, so you can still use absolute import syntax for this. i.e. import six will still just work, because it's in sys.path.
That said, the only place you have to use relative import syntax is to import stuff from within the same package. Plus, even in the hypothetical case where we did have that, as long as we don't write from future import absolute_import at the top of those packages' modules, they would still continue to work as they normally do.
It took me a while to wrap my head around this PEP, but now that I understand it, I think it's a good thing in principle, since it solves name collisions between your own modules and third-party / system modules by forcing you to make it explicit which one you want. Either you want a system / third-party module (e.g. import foo) or you want a module from within your current package (e.g. from . import foo)