... | ... | @@ -2,7 +2,9 @@ |
|
|
|
|
|
## General
|
|
|
- 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)
|
|
|
|
|
|
- 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
|
... | ... | @@ -13,26 +15,33 @@ |
|
|
|
|
|
## 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.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
## Documentation
|
|
|
- The plugin has comprehensive documentation on the:
|
|
|
|
|
|
- Usage
|
|
|
|
|
|
- Implementation
|
|
|
- Data fields imported, including datatypes of those fields
|
|
|
- What data is not imported
|
... | ... | @@ -43,5 +52,6 @@ |
|
|
|
|
|
## When using nbdev
|
|
|
- Notebooks should live in the /nbs folder.
|
|
|
|
|
|
- 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 |