pin all criticall pacakages in plugin installer

[Czaki]

This is my proposition for pining of dependency.

Instead of adding lower/upper bound for packages, Pin all packages that are critical to napari (list is currently incomplete)

We may not know about problematic versions, and maybe we should not allow for that without using external tools for environment management

[Czaki]

@psobolewskiPhD please see this as an alternative to #138.
This PR is to show idea, may need some tests, especially for conda env.

[Czaki]

I do not know how to prevent installing additional backend on conda.

[psobolewskiPhD]

@Czaki yeah i dont see anything easy. i think there would need to be a Qtbackend virtual package.
Otherwise, I think we'd need to have a recipe for a dummy package that we adjust the run_constraints of and then build the dummy package and install into the environment. I think that would work?

Edit:
On one hand I like the approach, on the other hand, this is really restricitve. I wonder if it's overkill?
I worry it may make debugging things more difficult?

[Czaki]

I think such an approach will be simpler to debug in bundled napari than "I have installed plugin and napari do not start"

[psobolewskiPhD]

Bundled napari is a different beast IMO.
I think constraining more severely has to happen there, because it's not easy to just make a new env and the target user is less advanced.

[psobolewskiPhD]

I almost wonder if we should split this in two:

• bundle plugin installer (which can also maybe handle napari updates)
• normal plugin installer, that defaults to conda or pip depending on the source of napari

[Czaki]

It may be a good idea.