Discussion about duplication of metadata in .napari-hub and python package metadata

[tlambert03]

The discussion of where plugin developers should enter specific metadata about their project has come up many times. While I know I've often requested that we try not to create new places to enter data that already has a "standard" place, I don't know that we have a running issue about it. So, I'd like to open this issue as a place to discuss it, and a somewhat more public request to remove some/all keys.

cc @neuromusic @potating-potato @jni @sofroniewn @DragaDoncila

My personal hope is that we can reduce the keys in .napari or .napari-hub to the bare minimum, and, preferably, to remove the file altogether. Below I discuss each key mentioned in the wiki at https://github.com/chanzuckerberg/napari-hub/wiki/Customizing-your-plugin's-listing#github

As you'll see below only 1 or two plugins have actually used any of these key in .napari or .napari-hub, so removing these from the spec and from the wiki should be quick and painless.

keys in .napari that are duplicated from core metadata that should be removed

I would propose that each of these be removed from .napari as soon as possible

• Summary

  only a single package (napari-features) has added a summary. unfortunately, they didn't include it in their setup.cfg metadata. (a good argument for removing it from .napari, since it should minimally be in setup.cfg). One PR would solve that.

Links

• Project Site

  this should be taken only from core metadata home page. only two plugins have used this so far.

Each of the following should just be a key that is looked for in core metadata project urls. See also the urls field in PEP621

• Documentation

  (only two plugins are using this, they should add it to core metdata)

• Support

  (three plugins are using this, they should add it to core metdata.)

• Report Issues

  (only one plugin is using this, they should add it to core metdata)

• Twitter

  (only one plugin is using this, they should add it to to core metdata)

keys in core metadata that might need to be duplicated

• Authors

  As I understand it, the motivation for this was to accept an orcid field, which is a nice idea. EP621 has made it possible to declare an inline table for project.authors... so it would be possible to declare something like this:

  [project]
  authors = [{ email = "mail@example.com", name = "My Name", orcid="01234-2354-345777..." }]

  setuptools will ignore that key, so it wouldn't make it into the dist-info of a wheel, but it's still probably the correct place to put it. Alternatively see [tool.napari] below.

• Description

  This is the one field that makes the most sense to potentially duplicate. Since it's certainly conceivable that someone would want to make their hub page look different then their readme and/or their pypi page... so, a single DESCRIPTION.md file remains the main thing I can't see a quick replacement for.

keys not in core metadata, that I don't think should go in .napari

• Conda

  see use npe2api in plugin install dialog napari/napari#4893 for some context. I'd prefer this not be in .napari at all, since it's not specific to the napari hub or display of a package on the hub. I would propose that it be moved either to a [tool.napari] section in pyproject toml (which is guaranteed to make it into the sdist) or to the manifest itself (which is guaranteed to make it into the wheel of a functioning plugin.)

• Visibility

  see Proposal: add visibility field to manifest schema, similar to original preview napari/npe2#196 for some context. I'd prefer this not be in .napari at all, since it's not specific to the napari hub or display of a package on the hub. I would propose that it be moved either to a [tool.napari] section in pyproject toml (which is guaranteed to make it into the sdist) or to the manifest itself (which is guaranteed to make it into the wheel of a functioning plugin.)

labels

Becuase of the PRs opened manually by the hub team, this is by far the most commonly used field, with about 20 plugins using it. This was originally in the npe2 manifest spec, but removed (the motivation for that removal is confusing to me, but in the past now). I'd propose this be readded to the manifest, but this would require opening new PRs to all those plugins that were previously instructed to put it in .napari.

pyproject.toml [tool.napari] or napari.yaml

For any plugin metadata that has a natural home in python's core metadata, i think we should absolutely use that field. There shouldn't be two places to enter the same thing.

For metadata that doesn't have a natural home in python's core metadata, we should probably use either a [tool.napari] section in pyproject.toml or add a new field to the napari.yaml manifest.

Looking forward to your feedback. thanks