Fix implicit napari dependency

[jni]

In #19 we picked up an undeclared dependency on napari:

napari-console/napari_console/qt_console.py

Line 19 in c15d804

from napari.utils.naming import CallerFrame

(thanks @tlambert03 for noticing.)

We're only using a small utility from napari, so we could either vendor it or pull it out into its own package...

[psobolewskiPhD]

Is there a drawback to a napari plugin depending on napari?
I'd say it's almost expected? What would this package provide outside napari that isn't already existing?

[jni]

I think there's a drawback to circular dependencies, and there's certainly drawbacks to tight coupling — where you can't change things in napari because of napari-console and vice versa.

[tlambert03]

In this case it would cause a circular dependency (since napari itself also depends on napari console). It's not a typical plugin, and another option is just to undo that (consume it again) and acknowledge the fact that napari depends on it.

[jni]

That is an option but not one I like! Again, it's not like we are using actual napari functionality here, just a stack inspection utility that we happened to implement in napari first.

[Czaki]

In the past, it crashed our constraints compilation. I think that the problem may be fixed.

[jni]

it crashed our constraints compilation

"it"?

[Czaki]

Having napari as dependency of napari dependency:

napari/napari-svg#34
napari/napari#5904

[jni]

I think in general though it's not good practice and probably a code smell to have cycles in a dependency graph? (Even if the tools can work around it.)

[tlambert03]

Not sure if it was clear, but I meant the other way around. Since napari console is in naparis deps, maybe just make it part of napari again, (vendored) until you're willing to remove it from the direct deps. What purpose does it serve as an independent thing that only works with napari?

[jni]

The goal is to make it a proper plugin — get rid of napari's dependency on napari-console altogether (though we would distribute it as part of the "essentials" in the bundle and napari[all]). (See also napari/napari#4740 😉) Then sure, this can just depend on napari. But yeah moving it in to (hopefully immediately 😅) pull it out does not sound appealing.

So I think that's the answer then — removing the dependency breaks the cycle.

In the meantime, things are basically working so I think this can be ignored?