Hey everyone, this is getting big :) Sorry I won't answer to all the great points both Matts, Stéfan, Riadh, Greg and Juan put here, but: [TL;DR] 1. Sorry Juan, I take it back! :) 2. How about skimage.v0?
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.
I was one of the first naysayers, and I'd like to take it back. I'd prefer us having the library going forward in the direction we planned than having to wait some ages to propose the API and general changes we would like to do. On the names: I humbly think that "skimage" should always point to the latest version. I like the idea of using "from skimage.v0 import ...", for instance. The breakage would be minimal, we still would have v0 in a clean way, and we have the space to go wild in 1.0. If we have the same discussion in 10 years for skimage 2, we can have "from skimage.v1 import ..." and we go on with our lives. I think that is the closest we'd get to please Greeks and Trojans (agradar gregos e troianos, in good Portuguese) :) My two BRL cents, though. Kind regards, Alex On Tue, 2021-07-20 at 11:11 -0700, Stefan van der Walt 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.
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.
Stéfan
_______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org https://mail.python.org/mailman3/lists/scikit-image.python.org/ Member address: alex.desiqueira@igdore.org
-- -------------------------------------------------- Dr. Alexandre de Siqueira Berkeley Institute for Data Science - BIDS 190 Doe Library University of California, Berkeley Berkeley, CA 94720 United States Lattes CV: 3936721630855880 ORCID: 0000-0003-1320-4347 Github: alexdesiqueira Twitter: alexdesiqueira --------------------------------------------------