Stabilise `guiclass`

[multimeric]

It looks like @guiclass was added in November 2022, so it's coming up on two years since it was added. However it's still marked as experimental, so I've held off actually using it. I wonder if there's any plan to stabilise the interface and remove the experimental label?

[Czaki]

From my point of view, there is no so big feedback for this feature, so it may be challenging to decide if the API is mature enough.

[multimeric]

Hmm, this might become a bit of a circular problem in that case. Maybe you could stabilise it and just be open to making new major versions that change the API?

[tlambert03]

Thanks for the note @multimeric,

I do tend to agree with @Czaki that we have very little to go on. That said, while I don't necessarily think that one always has to move a feature outside of experimental to get anyone to try to use it, in this case, since it's been two years of relative silence, I guess perhaps we are in that case. I don't love the concept of simply moving it into public API just to retrieve feedback (and I also don't feel that using major version numbers is "honest" in terms of the stability of the public API).

May I ask whether you've tried it at all? Or are you in the camp where you basically won't touch features as long as they're in experimental?

I can think of a few things off the top of my head that I felt weren't quite ready, so I know i'm not ready to simply move it out of experimental without addressing those things; but it would really be great to get a little feedback from you or other potential users first.

In any case, thanks for raising the issue, it moves it back on top of the list of considerations

[multimeric]

May I ask whether you've tried it at all? Or are you in the camp where you basically won't touch features as long as they're in experimental?

It depends on the nature of the project. As it is, I'm using magicgui for a production napari plugin, so it would be irresponsible of me to use a feature that could break without there being a way to prevent this using semver. If it were a hobby project I might consider using it.

[jni]

it would be irresponsible of me to use a feature that could break without there being a way to prevent this using semver.

I think you are overestimating the overall stability of the napari ecosystem as a whole @multimeric. Apart from SemVer won't save you, napari itself is quite unstable, and APIs might be deprecated across several patch versions for example. We haven't yet made it official but I think napari can be described as using EffVer, along with others in the SciPy ecosystem such as matplotlib.

imho the "responsible" way to deal with this on the user end is to use a feature and provide (but don't require) lock files with known-working environment configurations. (And you can even do this retrospectively with uv pip install --exclude-newer.)

[tlambert03]

agreed. And to add to that, surely there must be some way for you to try the feature to provide feedback without fully committing to incorporating it deeply (if you're worried about it). So, i'd ask again: have you tried it? perhaps in a branch, etc? Or will you simply not even experiment with it until it's out of experimental?

[multimeric]

No I haven't tried guiclass at all, just browsed through the docs and thought it sounded like a useful API.

If it helps, another way to think of it is that I am choosing to focus on the technologies that will reduce the maintenance effort, namely avoiding experimental features and major library upgrades due to my limited time.

[Czaki]

And we cannot stabilize API from features that we are not using, and we do not have feedback because of our limited time.
If we spot that some change is breaking change, we try to provide a fallback and deprecation warning.