Decide which modules should define __all__
While refactoring I noticed that we define __all__ in some modules that are not __init__.py files representing a package. Is that something that we want to do or care about very much? I would be fine relying solely on underscore prefixes in all modules that are not packages and only implementing __all__ for package files, but I don't feel strongly about this. I just wanted to raise the question for consistency's sake.
In theory we should define __all__ for every public API in the namespace that we intend to expose it in. So maybe this is only needed for package __init__.py files, specifically like the root and migration directory.
I would consider publicly visible modules to also be part of the public API. They may not be how we most frequently interact with packages, but there are many packages that expose functionality that way for a variety of reasons (even synced_collections does this). So things like signac.sync and signac.diff are part of the API too I would say.