Merge sprint #5

.dockerignore

@@ -1,7 +1,2 @@
 .vscode/
-docs/build
-*.pyc
-build/
-dist/
-*.egg-info/
-.eggs/
+build/

.github/workflows/ci.yml

@@ -24,4 +24,4 @@ jobs:
         pip install wheel
         pip install -r requirements.txt
     - name: Build docs
-      run: python setup.py install
+      run: sphinx-build docs/source docs/build/html

.gitignore

@@ -1,7 +1,2 @@
 .vscode/
-docs/build
-*.pyc
-build/
-dist/
-*.egg-info/
-.eggs/
+build/

docs/source/api_ref.md

@@ -1,4 +1,4 @@
-```eval_rst
+```{eval-rst}
 .. raw:: html
 
     <h1>API Reference</h1>
@@ -7,14 +7,14 @@
 This document is for developers and/or advanced users of OSP-core, it contains all API details.
 
 ## CUDS
-```eval_rst
+```{eval-rst}
 .. autoclass:: osp.core.cuds.Cuds
     :members:
     :show-inheritance:
 ```
 
 ## Ontology interface
-```eval_rst
+```{eval-rst}
 .. autoclass:: osp.core.ontology.namespace.OntologyNamespace
     :members:
     :special-members: __getattr__, __getitem__, __contains__, __iter__, __eq__
@@ -46,7 +46,7 @@ This document is for developers and/or advanced users of OSP-core, it contains a
 ```
 
 ## Sessions
-```eval_rst
+```{eval-rst}
 .. autoclass:: osp.core.session.session.Session
     :members:
     :show-inheritance:
@@ -73,14 +73,14 @@ This document is for developers and/or advanced users of OSP-core, it contains a
 ```
 
 ## Registry
-```eval_rst
+```{eval-rst}
 .. autoclass:: osp.core.session.registry.Registry
     :members:
     :show-inheritance:
 ```
 
 ## Utilities
-```eval_rst
+```{eval-rst}
 .. automodule:: osp.core.utils
    :imported-members:
    :members:

docs/source/conf.py

@@ -7,7 +7,6 @@
 # import os
 # import sys
 # sys.path.insert(0, os.path.abspath('.'))
-from recommonmark.transform import AutoStructify
 
 # -- Project information -----------------------------------------------------
 project = 'SimPhoNy'
@@ -18,7 +17,7 @@
 
 # -- General configuration ---------------------------------------------------
 extensions = [
-    'recommonmark',  # markdown source support
+    'myst_parser',  # markdown source support
     'sphinx.ext.autodoc',  # API ref
     'sphinx.ext.napoleon',  # API ref Google and NumPy style
     'sphinx.ext.viewcode',  # API link to source
@@ -60,18 +59,4 @@
 latex_logo = '_static/img/simphony_logo_dark.png'
 latex_elements = {'figure_align': 'H'}
 
-
-def setup(app):
-    # Configuration for recommonmark
-    app.add_config_value('recommonmark_config', {
-        # 'auto_toc_tree_section': 'Contents',
-        # 'enable_math': False,
-        # 'enable_inline_math': False,
-        'auto_toc_maxdepth': 2,
-        'enable_eval_rst': True,
-        # 'enable_auto_doc_ref': True,
-    }, True)
-    app.add_transform(AutoStructify)
-
-
 nbsphinx_allow_errors = True

docs/source/contribute.md

@@ -42,24 +42,23 @@ All wrappers and OSP-core are part of a common directory structure:
   An owner of the project should be tagged for review.
   They will review and merge the PR if the fix is correct, deleting the `issue branch` afterwards.
   The changes should be clearly explained in the issue/Pull Request.
-```eval_rst
-.. warning::
+```{warning}
    If the issue is a critical software bug detected in the stable release, a 
-   :code:`hotfix branch` should be created from the :code:`master/main` branch 
+   `hotfix branch` should be created from the `master/main` branch 
    instead. 
 
    After committing to such branch, a new Pull/Merge request (targeting 
-   :code:`dev`) should be created. If the fix is correct, the project owner 
-   will merge the PR to :code:`dev`, additionally merge the 
-   :code:`hotfix branch` to :code:`master/main`, and then delete the 
-   :code:`hotfix branch`.
+   `dev`) should be created. If the fix is correct, the project owner 
+   will merge the PR to `dev`, additionally merge the 
+   `hotfix branch` to `master/main`, and then delete the 
+   `hotfix branch`.
 ```
 - Once the features for a release have been reached, `dev` will be merged to 
   `master/main`. Every new commit in the `master/main` branch generally corresponds 
-  to a new release, which is labeled with a 
+  to a new release, which is labelled with a 
   [git tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging) matching its 
-  version number. An exception to this rule may apply, for example when several
-  critical hotfixes are applied in a row, as it would then be better to just to
+  version number. An exception to this rule may apply, for example when several 
+  critical hotfixes are applied in a row, as it would then be better to just to 
   publish a single release afterwards. In regard to version numbering, we adhere to the 
   [_Semantic versioning_](https://semver.org/) rules.