This has been rebased on master. I think the main point of discussion is what I've done to populate the __init__ file. I left in a private variable containing some developer notes:

__devnotes__ = """
CommandLine
-----------
# Run all tests in this subpackage
pytest networkx/algorithms/minors --doctest-modules
# Autogenerate the `__init__.py` file for this subpackage with `mkinit`.
mkinit ~/code/networkx/networkx/algorithms/minors/__init__.py -w
"""

This demonstrates how I used the mkinit package to autogenerate the explicit import statements instead of relying on import *. I imagine any points of contention in this PR would be

1. if that __devnotes__ comment should stay in the file or not,

2. the special __submodules__ attribute used by mkinit should be included or not

3. the fact that the comment is using a path on my system (it could be changed to point at a module-like path -- e.g. mkinit networkx.algorithms.minors instead -- which would be more universal), and

4. if I should just use import * anyway to be consistent with the current state of the package, even though there is discussion about moving away from that style.

That's all assuming there is support to move minors.py into a subpackage at all. (which I think there is a strong argument for)

@rossbar @dschult @jarrodmillman

@Erotemic Thanks for pushing this. (I haven't had time to think about making this a subpackage, but if @dschult agrees I am +1.)

I would like the __devnotes__ removed from this PR and I would like to settle on a consistent import pattern for NX (possibly using mkinit everywhere). We have a few different styles I suspect (though import * is probably the main style). It would be great if you could provide feedback on this PR:

• Implement lazy submodule importing scikit-image/scikit-image#5101

You may also want to quickly scan:

• Standard imports #4401
• Figure out how to best structure imports within the package #4426

Now that most of the major scientific Python core packages have dropped Python 3.6, we would like to implement lazy importing across the ecosystem (numpy, scipy, scikit-image, networkx, etc.). @stefanv created the PR on the scikit-image repo, since we were hoping to get more community feedback (but the idea started in #4401). Stefan is working on a PEP-like proposal to go with this PR, but it isn't ready yet.

I haven't looked at mkinit, but it looks like it may be helpful for moving in the lazy import direction. So it may make sense for us to use mkinit for the whole NX project and suggest using it in other projects if they are implementing the lazy import stuff. Maybe we could even add it to our CI system's style and formatting checker to make sure new contributions are being added to the _init__.py modules correctly.

The implementation of lazy initialization in scikit-image is interesting. Its likely that I could add a formatter to mkinit such that it generates a similar pattern based on its static analysis. I'll start thinking about that, see if I can put together a proof-of-concept implementation, and at that point I'll likely have delved into the issue enough to provide useful feedback.

My latest commit removes __devnotes__ (I did leave on small non-string comment at the bottom with one user-independent mkinit command, as it is very useful to have if you want to use mkinit to regenerate the file). This includes the new lazy import work discussed on scikit-image/scikit-image#5101. Of course we can switch back to eager with mkinit networkx.algorithms.minors --black -w or to lazy via mkinit networkx.algorithms.minors --black -w --lazy without much hassle. (We could also do a conditional check on some NETWORKX_EAGER_IMPORT environment variable so people have the option of front-loading all imports, which can be useful for long running processes).

I could also add a mode to mkinit to force the exiting import * method, so we can merge something consistent and then make the swap to lazy / explicit-eager in a separate branch? Or we could just merge this in lazy or explicit-eager mode and modify the rest of the library later (might be easier dev-time wise).

My preference would be to split the package reorganization and the import stuff into separate PRs. The proposed import system changes (lazy imports, mkinit, the ability to toggle, etc.) are interesting and (for me at least) it would be helpful to have them self-contained. It also would help un-stick the pkg/module reorg as I think the import changes need more attention & discussion whereas the module reorganization (coupled with following the existing import pattern with __all__) is a straightforward change that it seems everyone agrees with.

That makes sense, I'll revert this to the minimal changes.

@rossbar It only took me a month to get around to, but I made the small changes. This PR should be good to go.

Thanks @Erotemic !