Discussion: should we implement in-place update for the bundle?

[jni]

It has been a long-standing goal of mine that the bundle should update in-place. This is the standard workflow for ~all desktop applications.

@DragaDoncila told me that, at a community meeting, @psobolewskiPhD and @willingc expressed reservations about in-place update, specifically because an in-place update could break plugins.

I know that conda supports environment rollbacks, so I believe that this specific risk can be effectively mitigated, but I'll let @jaimergp weigh in on that.

On the plugin usability side, currently, installing a new version of the bundle means installing all plugins from scratch again, and we don't offer any solution for plugins that don't work anymore in this situation. (Other than of course the fact that the previous bundle would still be around.)

For me, the fact remains that users absolutely expect applications to update in-place, so we should see the above reservations as challenges to be solved for in-place updates, not as showstoppers.

[psobolewskiPhD]

I agree that typical applications do tend to autoupdate. But i'm not sure that is the best practice or the expectation in the imaging/scientific application space? Certainly that has not been my experience.

In my experience, it is not common for auto-updaters to exist and it is quite typical to not update, as projects can take longer than update cycles and because extensions/plugins/workflows might not be tied to specific versions.
People publish a paper with vX.Y.Z and then you should (try to) install and use that version.
Just as an example, for science stuff

• I currently have QuPath 0.2.3, 0.4.4, 0.5.1, and 0.6.0
• I currently have CellProfiler 3.1.9 and 4.2.6
• For napari I have 0.4.12, 0.4.17, 0.4.19, 0.5.6, 0.6.0, 0.6.1 and probably a host of others I'm forgetting.
• Fiji offers an updater, but the best practice is to disable it until you are done with your project or have a copy for each project.

Regarding napari bundle, I am concerned about breaking stuff due to dependencies/napari changes when napari is updated in place. Early in my napari days I broke envs when doing this and was wisely taught to make new envs liberally. For projects, I have named envs that I don't touch once i have what I need. I think rolling back can work with a condo-only env, but we do now support pip as well.

Regarding the hassle of migrating to a new version, we do have the Export/Import buttons in the plugin manager, so I think trying to migrate a set of plugins shouldn't be too bad that way --- assuming they continue to work in the target version...

So I'm really of two minds on this: yes there is some convenience, but there is also a cost and I am not convinced that it is an expectation that this is a thing.
Would be good to get more user feedback before we pursue this and I think that if it's implemented it should be opt-in.

[jni]

Thanks for the elaborate answer! "More research is needed" is a good conclusion. We could potentially add a specific question about this in the next iteration of the survey.

[TimMonko]

I really appreciate both your perspectives. I am especially sympathetic to Peter's response, given that I also work with similar users.
Indeed, I support bundle users and encourage them to make a new install if they want to try out things -- for them, recreating things with the plugin-manager is already a cakewalk, and for them also they get to "clean" up what plugins they actually want again. They are aware (from me) that this is likely to cause less breakage. It works for them, and for projects, I encourage them to rename the desktop icon specific to a bundle-project pair, so that they can easily use it. It's not so hard to install multiples of the same bundle, I support a user with three bundled 0.5.4 installs lol.

That said, I think it's a big lift to introduce something like "rollback" or whatever. And.. this sounds ever so difficult to maintain given the ever rapidly changing python environment management system we seem to have these days.

I'd more be in favor of in-place updates with a simple warning that pops up explicitly warning a user that this could break their bundle. I think FIJI has something kind of similar, and I would model our's to be similar. Warning, can be dismissed forever, but easily accessible via menus, if needed.

[Czaki]

I think that we may implement a popup about the new napari release.
We may even think about the simplicity of having multiple napari versions installed (maybe even some version manager).

[jaimergp]

We do have https://github.com/napari/update-checker, might need some love, but it's still there :)