search

Materials-Data-Science-and-Informatics / metador-core

Core of Metador, the FAIR metadata-first research data management framework.
MIT License
4 stars 0 forks source link

Metador plugins systems context #40

Closed broeder-j closed 2 years ago

broeder-j commented 2 years ago

Just to document some ideas:

  1. A simple registry for plugins is not a bad Idea. (I am happy to create one, along what aiida did).
  2. For the creation of plugins, (after going through the in depth tutorial which gets cluttered by the basics), once creating an actual plugin becomes more complicated, we might want to provide a cookiecutter (https://github.com/cookiecutter/cookiecutter) for metador plugins. I am thinking here of one cookiecutter for all plugin types. That the creation of all plugins goes as follows:
pip install cookiecutter
cookiecutter https://github.com/Materials-Data-Science-and-Informatics/metador-plugin-cutter.git

# fill command line prompts:
plugin name:
plugin type:

Project layout and structure done, entry point and everything done. (It could also ship with some basic tests of needed stuff to work properly and a setup CI and enforce so a certain level python.) Now we only need a tutorial on how to actually implement the thing and not so much the stuff around. A cutter could be connected to a helper tools, i.e I provide an external schema, the cutter gives me some implementation skeleton, which I just have to adapt.

What do you think? I would volunteer to do it, if I get the task to create some plugins I will probably even save time doing the template.

apirogov commented 2 years ago

Concerning cookiecutter, I totally agree and would be happy to see it done! (also this part is duplicate of #14 )

Concerning the plugin registry: that also would be nice, down the road. But obviously it would only make sense when the plugin ecosystem actually starts to grow. I will keep this issue open for the plugin registry aspect.