On Tue, Jul 20, 2021, at 05:32, Gregory Lee wrote:
This prevents the Hinsen-style breakage because "import skimage" would immediately fail in 1.0, but old codes and existing libraries could be easily adapted to use skimage2.skimage until they have migrated to skimage2. It is also fine to remove "skimage2.skimage" in the next major release without causing silent breakage. Aesthetically, "import skimage2" is a little worse than "import skimage", but not something I am too concerned about.

To be fair to Juan, I think this was one of his initial suggestions, but some of us balked at the thought of renaming the library or maintaining two versions.  Hence the suggested technical footwork.

But, reading the arguments here, I am convinced that the only way to avoid Hinsen-type changes AND give programmatic errors for all future versions is to change the import name.

Then, there is the question of whether to support the existing API inside of `skimage2`.  My gut feel is to make different packages (`pip install scikit-image` becomes `pip install skimage2`), and to let people hang on to `import skimage` until they are ready to `import skimage2`.  We can also backport bugfixes for a while.

This is getting into the weeds, but if we go this route we should probably match the version numbers --- `skimage 2.0` imports as `skimage2` and simply skip 1.0.