On Tue, Jul 20, 2021 at 2:11 PM Stefan van der Walt <stefanv@berkeley.edu> wrote:
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.

Indeed, there is already a brief discussion of this alternative under "New package naming" within the Alternatives section of SKIP3. It was not discussed in the context of this Hinsen-style breakage there, though, so I thought it was worth noting that as one point in its favor. One point listed against it in the SKIP is potential to increase fragmentation by reducing pressure on downstream libraries to update to the new API.

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.


scikit-image mailing list -- scikit-image@python.org
To unsubscribe send an email to scikit-image-leave@python.org
Member address: grlee77@gmail.com