fix(imports): remove dunder init

[paul-nechifor]

Problem

• We have a lot of __init__.py files which aggregate imports. This causes us to waste time importing things we don't need. Jeff has merged a solution to this ( Import Fix & Optimize: G1 without ROS, lazy imports, Fix bad dir naming, DIM-457, DIM-458, DIM-460, DIM-461 #1221 ), but I don't see why we need to bother re-exporting things to begin with. It's so much easier to import from the source.

• What bugs me is that when we re-export, we end up with two (or more) paths from which we can import the same thing. The codebase has this a lot.

• You always have to double check what you're importing. This occurs when a re-export shadows a module with a function within it. For example imagine you have def foo in dimos/core/foo.py. You use foo(…) in your code and you have to import it. Which import do you add? from dimos.core import foo or from dimos.core.foo import foo. The second is always reliable. But the first depends on whether dimos/core/__init__.py re-exports def foo. If it does not, then from dimos.core import foo is still valid, but it's not the function, it's the module. Allowing re-exports leads to uncertainty.

• If the worry is that removing them creates long imports for users, then there is a solution for this. We can create a single file of lazy imports at the root defining our entire public API. But internally, we should just import things from where they are defined.

Closes DIM-534

Solution

• Remove all __init__.py files.
• Fix all the imports to import from the source.
• Add a test to make sure new __init__.py files aren't added again.

Breaking Changes

• You have to import from the source now.

How to Test

...

Contributor License Agreement

• I have read and approved the CLA.

[leshy]

brutal but I agree, best approach for this

Briefly investigated how other large libraries do this, they do have diff (but similar) approaches to dealing with init and I agree that Pauls approach here seems best

[leshy]

I assume these changes are related to not requiring (even empty) init files for mypy etc?

edit

yes!