Change the default plugin name from `napari-foobar` to anything that doesn't start with `napari`

[DragaDoncila]

Since we no longer need the napari- prefix to find plugins, and it's not a very useful prefix to have when browsing for plugins, we should change the default plugin name to something else, to encourage new users to not have napari as the first word in their package name.

[tlambert03]

I dunno... while I agree that having everything start with napari- in the hub or the plugin browser seems repetitive, if the sole purpose of the thing is to be a napari plugin, then not having it in the name makes it far less digestable in the broader python ecosystem (this is why, for example, all pytest plugins start with pytest- and all flake8 plugins start with flake8- and all django plugins ... etc...) I certainly think that some plugins shouldn't start with napari (if they have use outside of napari), but if the sole purpose is napari, I don't think it's bad.

If this is just about browsing, then I think we could have a checkbox that strips the napari- prefix in whatever browser is being used

[DragaDoncila]

If this is just about browsing, then I think we could have a checkbox that strips the napari- prefix in whatever browser is being used

I don't really think that's a good decision, as the package name is the package name, and we shouldn't be changing it. I take your point that if it's just a napari plugin maybe it should have napari in the name though.

I guess what we really want here is better adoption of the display_name, so maybe we should change the prompt for the display_name to provide more context? And maybe we can change the name from napari-foobar to, idk something more meaningful like napari-segmentation and the display name to Image Segmentation?

[tlambert03]

just as we convert the package name to an underscore for the top level module, we could add a display name option to the cookiecutter and give them a suggestion (stripping the napari- and using title case)?

[jni]

Meh. I'm anti-prefix myself, but I have weak opinions about the cookiecutter — I'll just change the name as I please. I don't think it's nice to have the prefix in all the package names and I generally dislike when metadata makes its way to names of things. Ultimately we have many ways for plugins to advertise that they are a napari plugin other than the package name.

But, as I said, I don't have a strong preference here, just making my weak one known.

[tlambert03]

huh, so when you're looking at a list of installed things, or dependencies, and you see flake8- or django-, you have no opinion on it? For me, while there are certainly other ways to know something about a package (e.g. I could find their repository and look in their classifiers to see if they support a given thing), if the sole purpose of something is to be, say, a flake8 or django plugin, then that starts to become a bit more than just a little metadata, and i think elevating it into the naming makes sense. (and I like it when reviewing a list of installed things or dependencies... it immediately tells me if this thing may or may not make sense in my environment)

[jni]

Ok but you can't make me change the zarpaint or affinder names 😂

I agree that it's interesting when looking a pip lists. I suppose I don't look at them that often — I typically prefer to nuke an environment than to dig deep. 😂

[jni]

I'll note that it's easy to find napari plugins with napari --plugin-info. And I would hope pytest and co would offer similar functionality?

[tlambert03]

Ok but you can't make me change the zarpaint or affinder names

wouldn't dare! :) I have nothing against names without the prefix ... (and if a package could be used without napari, then I think it probably shouldn't have the prefix).

I'll note that it's easy to find napari plugins with napari --plugin-info.

yes, but again, I think you're being a bit napari-centric here :) (just as the original post when considering "how it looks in a napari search"). napari --plugin-info tells you something once you've got napari installed. the package naming is a universal python ecosystem indicator. that's the part I care about here. If a python package exists for the sole purpose of use with another python package, i think prefixing it with the name of that other package is a reasonable thing to do. As soon as that premise doesn't hold, then yes of course, name it whatever you want

edit: put another way, if we had our own package index (outside of pypi or conda), then I'd say leave off the napari. but we don't... we play in a world with others. If i installed a few things in an environment unrelated to django, and I started seeing a bunch of django-X in my pip list, I'd start wondering "who's bringing this stuff down??" and I'd know exactly where to start looking.

[DragaDoncila]

@jni yeah I agree with @tlambert03 that, in general, in the big wide world of python packages, it'd be nice for our plugins to be prefixed with napari. I also don't think we should name mangle the actual package names for browsing (either in viewer or in the hub). For display and information conveying purposes, we have the display_name metadata and that's what I think we should leverage here.

Hence, my proposal is to change the default plugin_name in the cookiecutter prompt to napari-seg (kinda meaningful but not very informative and starts with napari) and the display_name prompt to Threshold Image Segmentation (very meaningful, informative, and doesn't start with napari).

[Czaki]

The #142 change only display name, not plugin name itself

[jni]

@Czaki but if you see the discussion above, it seems most folks don't want the plugin name to not start with napari-. I still disagree but I understand the arguments so 🤷. I'm ok with closing this as wontfix.

[jni]

(But I'm also ok with reconsidering!)

[Czaki]

I'm ok with this. But it still should not be marked as solved. Feel free to close as not planned (for me).

[TimMonko]

Since this is still open, just want to add my thoughts as a new developer. This statement by @DragaDoncila:

my proposal is to change the default plugin_name in the cookiecutter prompt to napari-seg (kinda meaningful but not very informative and starts with napari) and the display_name prompt to Threshold Image Segmentation (very meaningful, informative, and doesn't start with napari).

is the implicit logic that prompted me when I was using the cookie cutter for the first time. I ended up using napari-x for plugin name but X-name for display_name. It made sense to me, and was consistent with how I also search for napari plugins to begin with and how I prefer to see their display names in napari's menus.

[DragaDoncila]

I'm happy with having the napari prefix still in the prompt for package name, and I like that we've changed the prompt for the display name. I think @TimMonko if I understand correctly, you agree with this logic also, so I'm going to close with as not planned. Folks please chime in or open a new issue if there's still changes desired 😊