Removed sphinx and added mkdocs (#685)

.circleci/config.yml

@@ -55,7 +55,7 @@ jobs:
           name: API Doc generation
           command: |
             . ~/venv/bin/activate
-            make sphinx
+            make mkdocs
       - run:
           name: Build wheel
           command: |

Makefile

@@ -29,9 +29,9 @@ lint:
 test:
 	pytest $(pkg_src)
 
-.PHONEY: sphinx ## Generate API docs using sphinx
-sphinx: 
-	sphinx-apidoc -o docs -f ./$(pkg_src) && sphinx-build ./docs build/docs
+.PHONEY: mkdocs ## Shortcut for mkdocs command
+mkdocs: 
+	mkdocs build
 
 .PHONY: install  ## Install the requirements
 install:

docs/ID-Mapping/index.md

@@ -0,0 +1,54 @@
+# ID-Mapping introduction
+
+## What is an ID-type?
+
+## Adding a mapping between two ID-types
+
+In your `__init__.py` of your plugin, you can add a new mapping via the `mapping_provider` extension point:
+
+```python
+registry.append('mapping_provider', '<my_mapping_provider_id>', '<my_plugin>.my_mapping_provider')
+```
+
+The new file `<my_plugin>.my_mapping_provider.py` containing the mapping provider, i.e. a create
+function returning mapping tuples (these can be dynamically generated, coming from a db, request, ...):
+
+```python
+def create():
+  return [
+    ('from', 'to', lambda ids: [[f'converted_{id}'] for id in ids]),
+    ('to', 'from', lambda ids: [[id[10:]] for id in ids]),
+  ]
+```
+
+Each tuple is basically `(from_idtype, to_idtype, mapping_function receiving multiple ids returning multiple ids for each id)`. Generally, the first id returned by the mapping function is preferred, however all are returned by default.
+
+!!! note
+
+    By simply defining tuples between id-types, powerful transitive mappings can be resolved by traversing the resulting graph. Visyn Core utilizing such a graph to allow for transitive mappings. 
+
+    Example:
+    Imagine registering the tuples `IDTypeA -> IDTypeB` and `IDTypeB -> IDTypeC`. With that, the transitive connection between `ÌDTypeA -> IDTypeC` is possible by first executing `IDTypeA -> IDTypeB`, followed by `IDTypeB -> IDTypeC`.
+
+## Mapping between two ID-types
+
+ * You can test it by showing all possible idtypes:
+
+[http://localhost:9000/api/idtype](http://localhost:9000/api/idtype)
+
+ * Or where 'from' can be mapped to:
+
+[http://localhost:9000/api/idtype/from](http://localhost:9000/api/idtype/from)
+
+ * Or mapping 'from' to 'to' for some ids:
+
+[http://localhost:9000/api/idtype/from/to?q=1,2,3](http://localhost:9000/api/idtype/from/to?q=1,2,3)
+
+ * Or mapping 'to' to 'from' for some ids:
+
+[http://localhost:9000/api/idtype/to/from?q=converted_1,converted_2,converted_3](http://localhost:9000/api/idtype/to/from?q=converted_1,converted_2,converted_3)
+
+ * Or mapping 'from' to 'to' for some ids and only wanting the first mapped id each:
+
+[http://localhost:9000/api/idtype/from/to?q=1,2,3&mode=first](http://localhost:9000/api/idtype/from/to?q=1,2,3&mode=first
+)

docs/commands/command-extension-point.md

@@ -0,0 +1,29 @@
+# `command` Extension Point
+
+The `command` extension point supports adding custom commands which are executed within the server context, i.e. with loaded plugin registry, migrations, etc. These command override the default server startup and execute the command only. 
+
+## Register a custom command
+
+Registering custom commands is considered legacy and will not be discussed thoroughly. 
+
+## Running a custom command
+
+The python module `tdp_core.cmd` can be used as executable module to run any registered command. The corresponding call (executed in the same bash where the server is usually executed, i.e. docker if in dockerized environment) looks like this:
+
+```bash
+python -m tdp_core.cmd <cmd-id> <cmd-arg1> <cmd-arg2> <...>
+```
+
+More concretely, one can trigger a database upgrade using the following command:
+
+```bash
+python -m tdp_core.cmd db-migration <migration-id> upgrade head
+```
+
+And a complete downgrade using following command:
+
+```bash
+python -m tdp_core.cmd db-migration <migration-id> downgrade base
+```
+
+Please see the official alembic documentation regarding database migrations: [https://alembic.sqlalchemy.org/en/latest/api/commands.html](https://alembic.sqlalchemy.org/en/latest/api/commands.html).

docs/commands/index.md

@@ -0,0 +1,2 @@
+# TODO: Commands introduction
+

docs/database/index.md

@@ -0,0 +1,2 @@
+# TODO: Databases introduction
+

docs/development/index.md

@@ -0,0 +1,33 @@
+# TODO: Development Introduction
+
+All important scripts are exposed via the Makefile. Use `make help` to show all available commands. 
+
+## Formatting
+
+Use `make format` to reformat all corresponding files.
+
+## Linting
+
+Use `make lint` to check for linting issues.
+
+## Testing
+
+Use `make test` to run the available test-suites using pytest.
+
+## Writing documentation
+
+[mkdocs-material](https://squidfunk.github.io/mkdocs-material/) is used to write this documentation.
+
+### Commands
+
+* `make mkdocs new [dir-name]` - Create a new project.
+* `make mkdocs serve` - Start the live-reloading docs server.
+* `make mkdocs build` - Build the documentation site.
+* `make mkdocs -h` - Print help message and exit.
+
+### Project layout
+
+    mkdocs.yml    # The configuration file.
+    docs/
+        index.md  # The documentation homepage.
+        ...       # Other markdown pages, images and other files.

docs/development/workspaces.md

@@ -0,0 +1 @@
+# TODO: Developer Workspace

docs/index.md

@@ -0,0 +1,3 @@
+# Welcome to Visyn Core
+
+Visyn Core is the core of the Visyn Platform, an open-source platform for developing scalable web-based visual ananlytics platforms.

docs/middleware/index.md

@@ -0,0 +1,2 @@
+# TODO: Middleware
+

docs/plugins/index.md

@@ -0,0 +1,2 @@
+# TODO: Plugins and Extensions
+

docs/plugins/write-your-own-plugin.md

@@ -0,0 +1 @@
+# TODO: Write your own plugin

docs/security/index.md

@@ -0,0 +1 @@
+# TODO: Security

docs/settings/index.md

@@ -0,0 +1 @@
+# TODO: Settings

mkdocs.yml

@@ -0,0 +1,26 @@
+site_name: Visyn Core
+theme:
+  name: material
+  features:
+    - navigation.expand
+  palette:
+    - media: "(prefers-color-scheme: light)" 
+      scheme: default
+      primary: blue
+      toggle:
+        icon: material/toggle-switch-off-outline
+        name: Switch to dark mode
+    - media: "(prefers-color-scheme: dark)" 
+      scheme: slate
+      primary: blue
+      toggle:
+        icon: material/toggle-switch
+        name: Switch to light mode
+markdown_extensions:
+  - admonition
+  - pymdownx.highlight:
+      anchor_linenums: true
+  - pymdownx.inlinehilite
+  - pymdownx.snippets
+  - pymdownx.superfences
+  - pymdownx.details

requirements_dev.txt

@@ -2,8 +2,8 @@ black~=22.3.0
 debugpy~=1.5.1
 flake8~=4.0.1
 isort~=5.10.1
+mkdocs-material~=8.2.8
 pep8-naming~=0.12.1
 pytest-runner~=6.0.0
 pytest~=7.1.1
-recommonmark~=0.7.1
-Sphinx~=4.4.0
+recommonmark~=0.7.1

tdp_core/security/store/base_store.py

@@ -1,4 +1,4 @@
-from typing import Union
+from typing import Optional
 
 from fastapi import FastAPI, Request
 
@@ -18,5 +18,5 @@ def load_from_request(self, request: Request) -> User:
     def login(self, username: str, extra_fields={}) -> User:
         return None
 
-    def logout(self, user: User) -> Union[LogoutReturnValue, None]:
+    def logout(self, user: User) -> Optional[LogoutReturnValue]:
         pass

tdp_core/security/store/dummy_store.py

@@ -23,15 +23,6 @@ def is_password(self, given):
         return given_h == self.password
 
 
-def from_env_var(k, v):
-    elems = v.split(";")
-    name = k[12:]  # PHOVEA_USER_
-    salt = elems[0]
-    password = elems[1]
-    roles = elems[2:]
-    return DummyUser(id=name, name=name, roles=roles, password=password, salt=salt)
-
-
 class DummyStore(BaseStore):
     def __init__(self):
         self._users = [