@zyzzyxdonta Nice one! 🚀

I like this simple impl! A few comments:

• One thing I'd like to see added to the metadata is the type of the plugin, i.e., the step that this plugin targets. This will help filtering and could be used to display plugins of the same type under dedicated subheadings.
• In a next step, perhaps we could add another optional field that describes the filetypes (via, e.g., filename or schema) that a plugin works on? This makes sense mainly for harvest plugins, but I'd rather have an optional field that goes unused than introduce plugin metadata inheritance ;).
• At some point, we should probably provide a JSON schema for the plugin metadata?
• For now, having a centralized list of plugins makes sense. If at some point this becomes feasible, it could be better to let each plugin have its own metadata in its repo, where the marketplace retrieves it from. This way, plugin authors keep the metadata where the plugin is developed for easier updates. And we have less maintenance work to do, and a simple automated registration of a new plugin would suffice (register via issue, closing issue triggers CI to pull metadata and re-render marketplace).

Thoughts?

• One thing I'd like to see added to the metadata is the type of the plugin, i.e., the step that this plugin targets. This will help filtering and could be used to display plugins of the same type under dedicated subheadings.

Done.

@zyzzyxdonta Nice one! 🚀

I like this simple impl! A few comments:

• One thing I'd like to see added to the metadata is the type of the plugin, i.e., the step that this plugin targets. This will help filtering and could be used to display plugins of the same type under dedicated subheadings.

...

Thoughts?

I think it's important to have the steps annotated but I think this is not a one-to-one relationship. I would expect a Python plugin to contain a harvester and maybe a PyPI deposit and even a post-processor. Our CFF post-process could also be coupled with the harvester if it was a plugin...

I think it's important to have the steps annotated but I think this is not a one-to-one relationship.

I've taken this into account by allowing multiple steps to be listed. If a plugin targets multiple steps, it appears in all of the related lists for now.

I wrote a simple Sphinx extension to get rid of the horrible templating of the JSON-LD markup 🙈

Builtin plugins are now marked using schema:isPartOf <hermes>.

• One thing I'd like to see added to the metadata is the type of the plugin, i.e., the step that this plugin targets. This will help filtering and could be used to display plugins of the same type under dedicated subheadings.

• In a next step, perhaps we could add another optional field that describes the filetypes (via, e.g., filename or schema) that a plugin works on? This makes sense mainly for harvest plugins, but I'd rather have an optional field that goes unused than introduce plugin metadata inheritance ;).

How about using schema:featureList to mark the targeted steps? And schema:keywords for handled file types?

Added hermes-marketplace command which requests the list of known plugins from the website and prints it as follows:

See the detailed list of plugins here: https://hermes.software-metadata.pub#plugins

                  CITATION.cff  (builtin)
                 codemeta.json  (builtin)
             hermes-plugin-git  https://github.com/softwarepub/hermes-plugin-git
          hermes-plugin-python  https://github.com/softwarepub/hermes-plugin-python
                         Merge  (builtin)
                        Curate  (builtin)
               Invenio Deposit  (builtin)
           Invenio RDM Deposit  (builtin)
                Rodare Deposit  (builtin)
           Invenio Postprocess  (builtin)
       Invenio RDM Postprocess  (builtin)

Please note that in order to test this command, the MARKETPLACE_URL in src/hermes/commands/marketplace.py has to be adapted to wherever you deploy your docs pages during testing (likely "http://127.0.0.1:8000")

I feel like we could have a common data model (e.g. pydantic model) between the Sphinx extension and the hermes-marketplace command. 👀 Even third-party plugins could then use it to publish their plugin metadata "correctly". But this would require them using Sphinx while a simple JSON file in a repo or a JSON-LD script in the README is way simpler.

• At some point, we should probably provide a JSON schema for the plugin metadata?

Done

I'll mark this as ready for review now. These are open questions:

• How to express in Schema.org the Hermes workflow steps targeted by the plugin? schema:keywords? schema:featureList?
• How to express in Schema.org the file types understood by a harvesting plugin? schema:keywords? schema:featureList?

This is what the issue template looks like (though some fields will be shown as required which doesn't work in the private repo I used for testing, and the unnecessary line break before the marketplace link is fixed):

• How to express in Schema.org the Hermes workflow steps targeted by the plugin? schema:keywords? schema:featureList?

• How to express in Schema.org the file types understood by a harvesting plugin? schema:keywords? schema:featureList?

I opted for keywords for everything.

• Plugin type: hermes-step-harvest, hermes-step-process, ...
• Filetype: hermes-harvest-citation-cff, hermes-harvest-pyproject-toml, ...