On Tue, Jul 20, 2021 at 7:35 AM Riadh <rfezzani@gmail.com> wrote:

Hi,

Le 20/07/2021 à 12:21, Matthew Brett a écrit :
> I think the underlying problem here is that developers generally have
> a very different set of instincts to users. Developers typically
> update their machines often, don't worry too much about code breaking,
> and may (although, surely this is uncommon?) pay some attention to
> changes in major version numbers. I think users generally do few of
> those things. I'm a developer, and I certainly don't expect huge API
> changes with changes in major version numbers, even though I know
> about semantic versioning. In practice, I think it is very uncommon
> to make large API changes between major versions, and especially,
> Hinsen-breakage API changes.

I agree with you, developers may even don't worry about code breaking,
as they may consider it as challenges to solve :D

> So I think it's fairly typical for developers to think 'What's the
> problem?', because this kind of problem isn't a problem for them. But
> I think you'll find it is a major problem for almost everyone who is
> not a scikit-image developer, and does use scikit-image, and
> especially those who are not reading this email thread.

This is not my reasoning: my point is that it is in fact not a problem
since a simple solution exists and is identified: communicate and offer
a clear documentation to the community.

> Just to return to the paragraph above, I bet that "users not adopting
> modern python programming convention" is a reasonable description of
> your average user.

You are right, and I bet that a large majority doesn't maintain a script
or a package that will break with the v1.0 release.

Users usually use the API as it is when they are coding. And more
"serious" coders usually care about code breaking, and if they do, they
pin they dependencies versions. If they don't, I am pretty sure that
they will be happy to learn how to do it ;)

> But - to return to the practical point - what is the extra work, and
> fracturing, that you see for the skimage / skimage2 option?
>
> If you don't want to maintain 0.18 / skimage - then no problem - just
> abandon skimage and work on skimage2.
>
> If you do want to backport fixes, then you might (or might not) find
> it easier to use skimage as a namespace, and use the current skimage2
> as the home of the real code.

Maintaining a second package also means managing the infrastructure
(Git, doc, CI, deployment...)

I don't think forking the repository and maintaining separate packages is a viable option, but we discussed the possibility of following a similar path to what OpenCV did when they released 2.0. At that point they changed the top-level import to cv2 and kept the old 1.x API available via cv2.cv. With OpenCV 3.0 they dropped cv2.cv altogether and are still using the cv2 import name today. If we did a similar thing with "from skimage2 import ..." (new API) vs "from skimage2.skimage import ..." (old API), it is still a bit more work for maintainers to test and maintain both namespaces, but we would still only have one "skimage" on pypi and could keep our existing infrastructure (I think this is also what Matthew was suggesting with possibly having the old API be implemented as thin wrappers around the new one)? 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.

> Now the question again - what is the real advantage of calling the new
> version skimage 1.0 instead of skimage2? I mean, in what sense is
> the community less fractured? At the moment I am stuck with the
> implausible answer that it's a good idea to break lots of code to
> force developers onto the new skimage 1.0 version from the old one.
> But you can't mean that. So - can you say more about what you do
> mean?

But what is the advantage of skimage2 vs skimage v1.0 if code break is a
fake problem? I still convinced that we are not breaking code:

```

conda create -n old_skimage_env skimage=0.18
conda activate old_skimage

python my_old_scipt_broke_by_v1.py

```

And finally, I am not sure, as a nostalgic skimage user, to be happy to
call `import skimage2` :)

Cheers,

Riadh.

_______________________________________________
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: grlee77@gmail.com