|
|
**A plugin is considered done when**
|
|
|
|
|
|
## General
|
|
|
- Your code is reasonably composed. Use small reusable blocks of code where possible.
|
|
|
- Your code is reasonably composed. Use small reusable blocks of code where possible.
|
|
|
- Your plugin is installable using a setup.py via pip install -e ., avoid assumptions about tooling as much as possible (don't introduce tools like poetry, pipenv, etc. without an application specific reason)
|
|
|
- There is a Docker file that installs all requirements to run the plugin. The CI should push the latest docker container to the registry
|
|
|
- The MPPL license is added to the repository
|
|
|
- In general, plugins should not store any personal data on disk. If a plugin absolutely needs this, make sure to discuss this with the memri team and make sure that the data is encrypted at all times (also when its in a database). The decryption keys should be stored only in the pod
|
|
|
|
|
|
- Your plugin is installable using a setup.py via `pip install -e .`, avoid assumptions about tooling as much as possible (don't introduce tools like poetry, pipenv, etc. without an application specific reason)
|
|
|
|
|
|
- Your plugin is configured to run as a daemon, in the case that your plugin needs to import continuously (for instance for a messenger)
|
|
|
- There is a Docker file that installs all requirements to run the plugin
|
|
|
- Approved schema is added to https://gitlab.memri.io/memri/schema for those fields that are common
|
|
|
- You issue a Merge Request (MR) against a first commit that is a copy of the plugin-template.
|
|
|
- The [MPPL license](https://memri.io/license.html) is added to the repository
|
|
|
- The right icon/logo of the service is added to the repository (when applicable)
|
|
|
- In general, plugins should not store any personal data on disk. If a plugin absolutely needs this, make sure to discuss this with the memri team and make sure that the data is encrypted at all times (also when its in a database). The decryption keys should be stored **only** in the pod
|
|
|
|
|
|
## Data
|
|
|
- When running an importer: all relevant data is imported to the Pod (defined per plugin)
|
|
|
|
|
|
- Data is imported incrementally: Data is not duplicated / stored twice when the plugin imports data multiple times.
|
|
|
|
|
|
- When running an importer (a specific type of plugin): all relevant data is imported to the Pod (defined per plugin)
|
|
|
## Tests
|
|
|
- Most importantly, the plugin contains a test that runs it end-to-end using `run_plugin(from_pod=True)` on a small sample of data. The readme exactly describes how to run this test, without making assumptions about what has been installed (other than `pip install -e .`)
|
|
|
|
|
|
- the plugin works on 5 real world accounts
|
|
|
- A test account for the corresponding service, which holds example data of all the imported data types, with enough variation to catch most edge cases
|
|
|
- Mocking for the tests dependent on the external service
|
|
|
- CI runs tests to see whether all data types are downloaded, stored and connected in the Pod
|
|
|
- There are unit tests where possible: for instance for parsing, inference, etc..
|
|
|
- If you are creating a plugin as a regular python project, use pytest for testing.
|
|
|
|
|
|
- If you are using nbdev, you can use nbdev_test_nbs.
|
|
|
|
|
|
- importer plugins should contain a test that imports a mock response from the 3rd party API into the pod. The readme exactly describes how to run this test, without making assumptions about what has been installed (other than pip install -e .)
|
|
|
- CI runs the mock test successfully
|
|
|
## Authentication
|
|
|
- Authentication is implemented
|
|
|
|
|
|
- A clear description of how credentials are made available to the plugin, in order to enable front end and platform developers to implement that
|
|
|
|
|
|
- A clear description of what trust we are asking from users, e.g. are they storing their credentials on the server their Pod is hosted, is communication encrypted, etc.
|
|
|
|
|
|
- A clear description of how credentials are made available to the plugin, in order to enable front end and platform developers to implement that
|
|
|
- A clear instruction how a new user can setup up their credentials and run the plugin
|
|
|
## Documentation
|
|
|
- The plugin has comprehensive documentation on the:
|
|
|
|
|
|
- Usage
|
|
|
|
|
|
- Implementation
|
|
|
- Data fields imported, including datatypes of those fields
|
|
|
- What data is not imported
|
|
|
- Frequency the plugin can run (this should be <5 min for social services, and not e.g. only daily because of use of GDPR requests)
|
|
|
- Time it takes to run the plugin
|
|
|
- System requirements (RAM, CPU, disk and others if relevant)
|
|
|
- The authentication flow: What login mechanism is used, how is 2FA handled, etc.
|
|
|
|
|
|
## When using nbdev
|
|
|
- Notebooks should live in the /nbs folder.
|
|
|
The plugin has comprehensive documentation on the:
|
|
|
- Usage and authentication steps
|
|
|
- Classes imported
|
|
|
|
|
|
- In nbdev notebooks are meant for building the lib and writing tests, not for scripts. If you want to add a scripts, create a /scripts folder and add it there.
|
|
|
- If you have ci setup to generate docs, request a memri maintainer to activate gitlab pages. |
|
|
\ No newline at end of file |