cgse 2025.0.3__tar.gz → 2025.0.6__tar.gz

{cgse-2025.0.3 → cgse-2025.0.6}/NOTES.md

@@ -55,29 +55,6 @@ Note that each library or project is a standalone Poetry package with its own `p
 
 All packages in the monorepo will have the same version. This can be maintained with the `bump.py` script. This script will read the version from the `pyproject.toml` file at the root of the monorepo and propagate the version to all libs and projects in the monorepo. Note that you –for now– will have to update the version number in the `pyproject.toml` file  located at the monorepo root folder manually. 
 
-# Use of Poetry (DEPRECATED: see below)
-
-I have now Poetry configurations for all `libs` in this monorepo. So, how do we use Poetry in this project?
-
-First thing to understand, Poetry is a development and dependency management tool. So, if you are installing the different packages in this repo from PyPI there is no need to use Poetry. The package will be installed in your current virtual environment.
-
-You can choose how you want to manage your virtual environments for each of the packages in the monorepo. I personally use `pyenv` to manage my virtual environments and I disable the virtual environment that would normally be used by Poetry.
-
-> Explain how to use `pyenv` for your virtual environments
-
-The following command starts a new sub-shell and activates the virtual environment: 
-```
-$ poetry shell
-```
-
-If you do not want to start a new shell, but just want to execute a command in the virtual environment, use the `poetry run` command, e.g.
-```
-$ poetry run pytest tests/test_bits.py
-```
-Or
-```
-$ poetry run python -m egse.monitoring localhost 6001
-```
 
 # Build and Publish
 

{cgse-2025.0.3 → cgse-2025.0.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cgse
-Version: 2025.0.3
+Version: 2025.0.6
 Summary: Generic Common-EGSE: Commanding and monitoring lab equipment
 Author-email: Rik Huygen <rik.huygen@kuleuven.be>, Sara Regibo <sara.regibo@kuleuven.be>
 License: MIT

cgse-2025.0.6/conftest.py

@@ -0,0 +1,30 @@
+from glob import glob
+
+import rich
+
+# Quick hack to load plugins from different places.
+# This doesn't work, I get an import error.
+
+# def refactor(string: str) -> str:
+#     entry = string.replace("/", ".").replace("\\", ".").replace(".py", "")
+#     rich.print(f"[green]{entry = }[/]")
+#     return entry
+#
+# pytest_plugins = [
+#     refactor(conftest)
+#     for conftest in glob("**/tests/fixtures/*.py", recursive=True)
+#     if "__" not in conftest
+# ]
+
+# Doesn't work, with the following error:
+#
+# File "/Users/rik/github/cgse/libs/cgse-common/tests/fixtures/default_env.py", line 7, in <module>
+#     from fixtures.helpers import setup_data_storage_layout, teardown_data_storage_layout
+# ImportError: Error importing plugin "libs.cgse-common.tests.fixtures.default_env": No module named 'fixtures'
+#
+
+# pytest_plugins = [
+#     "libs.cgse-common.tests.fixtures.helpers",
+#     "libs.cgse-common.tests.fixtures.default_env",
+#     "libs.cgse-core.tests.fixtures.services",
+# ]

cgse-2025.0.6/docs/custom_theme/main.html

@@ -0,0 +1,32 @@
+{% extends "base.html" %}
+
+{% block extrahead %}
+<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/firacode/6.2.0/fira_code.min.css" integrity="sha512-MbysAYimH1hH2xYzkkMHB6MqxBqfP0megxsCLknbYqHVwXTCg9IqHbk+ZP/vnhO8UEW6PaXAkKe2vQ+SWACxxA==" crossorigin="anonymous" referrerpolicy="no-referrer" />
+<!-- Fathom - beautiful, simple website analytics -->
+<script src="https://cdn.usefathom.com/script.js" data-site="TAUKXRLQ" defer></script>
+<!-- / Fathom -->
+
+
+<meta property="og:title" content="CGSE - {{ page.title }}">
+<meta property="og:type" content="article">
+<meta property="og:url" content="{{ page.canonical_url | url }}">
+<meta property="og:site_name" content="CGSE Documentation">
+<meta property="og:description" content="CGSE is an instrument test framework for Python.">
+<meta property="og:image" content="https://raw.githubusercontent.com/IvS-KULeuven/cgse/refs/heads/main/docs/images/icons/cgse-logo.svg">
+
+<style>
+
+    @font-face {
+        font-family: "Virgil";
+        src: url("https://unpkg.com/@excalidraw/excalidraw@0.12.0/dist/excalidraw-assets/Virgil.woff2");
+      }
+      @font-face {
+        font-family: "Cascadia";
+        src: url("https://unpkg.com/@excalidraw/excalidraw@0.12.0/dist/excalidraw-assets/Cascadia.woff2");
+      }
+
+
+
+</style>
+
+{% endblock %}

cgse-2025.0.6/docs/dev_guide/index.md

@@ -0,0 +1,6 @@
+# Developer Guide
+
+Welcome to the CGSE developer guide! An in-depth reference on how to contribute to the CGSE.
+
+First thing to know is that this repository is actually a monorepo, meaning it contains a bunch of related but 
+self-standing packages with a minimum of interdependencies. These packages are  

{cgse-2025.0.3 → cgse-2025.0.6}/docs/dev_guide/uv.md

@@ -40,15 +40,23 @@ $ uv python install 3.9.20
 
 You can check which Python versions are installed already on your system:
 
-```shell
-$ uv python list --only-installed
-cpython-3.12.8-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.12.8-macos-aarch64-none/bin/python3.12
-cpython-3.10.16-macos-aarch64-none    /Users/rik/Library/Application Support/uv/python/cpython-3.10.16-macos-aarch64-none/bin/python3.10
-cpython-3.9.21-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.9.21-macos-aarch64-none/bin/python3.9
-cpython-3.9.20-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.9.20-macos-aarch64-none/bin/python3.9
-cpython-3.9.6-macos-aarch64-none      /Library/Developer/CommandLineTools/usr/bin/python3 -> ../../Library/Frameworks/Python3.framework/Versions/3.9/bin/python3
-cpython-3.8.17-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.8.17-macos-aarch64-none/bin/python3.8
-```
+=== "Command"
+
+    ```bash
+    $ uv python list --only-installed
+    ```
+
+=== "Output"
+
+    ```
+    cpython-3.12.8-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.12.8-macos-aarch64-none/bin/python3.12
+    cpython-3.10.16-macos-aarch64-none    /Users/rik/Library/Application Support/uv/python/cpython-3.10.16-macos-aarch64-none/bin/python3.10
+    cpython-3.9.21-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.9.21-macos-aarch64-none/bin/python3.9
+    cpython-3.9.20-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.9.20-macos-aarch64-none/bin/python3.9
+    cpython-3.9.6-macos-aarch64-none      /Library/Developer/CommandLineTools/usr/bin/python3 -> ../../Library/Frameworks/Python3.framework/Versions/3.9/bin/python3
+    cpython-3.8.17-macos-aarch64-none     /Users/rik/Library/Application Support/uv/python/cpython-3.8.17-macos-aarch64-none/bin/python3.8
+    ```
+
 
 ## Create a virtual environment
 
@@ -94,6 +102,19 @@ $ uv pip install -e .
     $ source .venv/bin/activate
     ```
 
+!!! info
+
+    In a workspace, maintaining a virtual environment per package might be a hassle and most of the time that is not 
+    needed. A good approach is to always use the virtual environment at the workspace root. This `venv` which will be 
+    automatically created if you run a command or if you use `uv sync` in the package folder. With `uv sync` you can 
+    make sure the virtual environment is up-to-date and contains only those dependencies that are required for the 
+    package you are in. So, each time you switch to another package and want to run a comand or a test for that 
+    package, use 
+
+    ```
+    $ uv sync
+    ```
+
 ## Building and publishing all packages
 
 We have chosen for one and the same version number for all packages in the `cgse` monorepo. That means that whenever 

cgse-2025.0.6/docs/getting_started.md

@@ -0,0 +1,91 @@
+All you need to get started using and building the CGSE.
+
+## Requirements
+
+- Python 3.9.x (we do not yet support higher versions, but are working to extend the list)
+- macOS or Linux
+
+## Virtual environment
+
+You should always work inside a virtual environment to somehow containerize your project such that it doesn't 
+pollute your global environment and you can run different projects next to each other. Create and activate a new 
+virtual environment as follows. It should be Python >= 3.9
+
+```shell
+$ python -m venv venv
+$ source venv/bin/activate
+```
+
+## Installation
+
+The easiest way to install the CGSE is to use the `pip` command. Since the CGSE is a monorepo and consists of 
+several packages, you will need to make your choice which package you need for your project. You can however start 
+with the `cgse-common` which contains all common code that is generic and useful as a basis for other packages.
+
+```shell
+$ pip install cgse-common
+```
+
+Check the [list of packages](./package_list.md) that are part of the CGSE repo and can be installed with `pip`. The 
+packages are described in more detail in the sections [Libs](./libs/index.md) and [Projects](./projects/index.md).
+
+## Set up your environment
+
+To check your installation and set up your environment, here are a few tips.
+
+The version of the core packages and any plugin packages can be verified as follows. The version you installed will 
+probably be higher and more lines will appear when other packages are installed.
+
+```shell
+$ py -m egse.version
+CGSE version in Settings: 2025.0.5
+Installed version for cgse-common= 2025.0.5
+```
+
+Check your environment with the command below. This will probably print out some warning since you have not defined 
+the expected environment variables yet. There are two mandatory environment variables: `PROJECT` and `SITE_ID`. The 
+former shall contain the name of your project without spaces and preferably a single word or an acronym like PLATO, 
+ARIEL, MARVEL, MERCATOR. The latter is the name of the site or lab where the tests will be performed. Good names are 
+KUL, ESA, LAB23.
+
+The other environment variables follow the pattern `<PROJECT>_...`, i.e. they all start with the project name as 
+defined 
+in the PROJECT environment variable. You should define at least `<PROJECT>_DATA_STORAGE_LOCATION`. The configuration 
+data and log file location will be derived from it unless they are explicitly set themselves. 
+
+
+Let's define the three expected environment variables:
+
+```shell
+$ export PROJECT=ARIEL
+$ export SITE_ID=VACUUM_LAB
+$ export ARIEL_DATA_STORAGE_LOCATION=~/data
+```
+
+Rerunning the above command now gives:
+
+```
+$ py -m egse.env
+Environment variables:
+    PROJECT = ARIEL
+    SITE_ID = VACUUM_LAB
+    ARIEL_DATA_STORAGE_LOCATION = /Users/rik/data
+    ARIEL_CONF_DATA_LOCATION = not set
+    ARIEL_CONF_REPO_LOCATION = not set
+    ARIEL_LOG_FILE_LOCATION = not set
+    ARIEL_LOCAL_SETTINGS = not set
+
+Generated locations and filenames
+    get_data_storage_location() = '/Users/rik/data/VACUUM_LAB'  ⟶ ERROR: The data storage location doesn't exist!
+    get_conf_data_location() = '/Users/rik/data/VACUUM_LAB/conf'  ⟶ ERROR: The configuration data location doesn't exist!
+    get_conf_repo_location() = None  ⟶ ERROR: The configuration repository location doesn't exist!
+    get_log_file_location() = '/Users/rik/data/VACUUM_LAB/log'  ⟶ ERROR: The log files location doesn't exist!
+    get_local_settings() = None  ⟶ ERROR: The local settings file is not defined or doesn't exist!
+
+use the '--full' flag to get a more detailed report, '--doc' for help on the variables.
+```
+
+!!! Note
+
+    The folders that do not exist (and are not None) can be created by adding the option `--mkdir` to the above 
+    command.

cgse-2025.0.6/docs/libs/cgse-common/index.md

@@ -0,0 +1,37 @@
+# Common Code
+
+
+This package `cgse-common` contains modules that are used by all other packages. 
+
+| Module Name        | Description                                                                     |
+|--------------------|---------------------------------------------------------------------------------|
+| `egse.bits`        | convenience functions to work with bits, bytes and integers                     |
+| `egse.calibration` | functions to handle conversions and apply correction                            |
+| `egse.command`     | classes and functions to work with commands that operate hardware devices       |
+| `egse.config`      | convenience functions to configure the system and find folders and files        |
+| `egse.control`     | defines abstract classes and convenience functions for any control server       |
+| `egse.decorators`  | a collection of useful decorator functions                                      |
+| `egse.device`      | defines the generic interfaces to connect devices                               |
+| `egse.env`         | functionality to work with and check your environment variables                 |
+| `egse.exceptions`  | common Exceptions and Errors                                                    |
+| `egse.hk`          | functions to retrieve and convert housekeping parameter values                  |
+| `egse.metrics`     | functions to define and update metrics                                          |
+| `egse.mixin`       | defines the mixin classes for dynamic commanding                                |
+| `egse.monitoring`  | the monitoring application / function                                           |
+| `egse.observer`    | the classic observer and observable                                             |
+| `egse.obsid`       | functions to define and work with the OBSID                                     |
+| `egse.persistence` | the persistence layer interface                                                 |
+| `egse.plugin`      | functions to load plugins and settings from entry-points                        |
+| `egse.process`     | functions and classes to work with processes and sub-processes                  |
+| `egse.protocol`    | base class for communicating commands with the hardware or the control server   |
+| `egse.proxy`       | base class for the Proxy objects for each device controller                     |
+| `egse.reload`      | a slightly better approach to reloading modules and function                    |
+| `egse.resource`    | convenience functions to use resources in your code                             |
+| `egse.response`    | defines the classes to handle responses from the control servers                |
+| `egse.services`    | provides the services to the control servers                                    |
+| `egse.settings`    | provides functions to handle user and configuration settings                    |
+| `egse.setup`       | defines the Setup, containing the complete configuration for a test             |
+| `egse.state`       | classes and functions to handle state, e.g. the GlobalState                     |
+| `egse.system`      | convenience functions that provide information on system specific functionality |
+| `egse.version`     | functions to load specific version information                                  |
+| `egse.zmq_ser`     | serialization function used in a ZeroMQ context                                 |

cgse-2025.0.6/docs/libs/cgse-common/settings.md

@@ -0,0 +1,253 @@
+# The Settings
+
+The Settings class contains all static information needed to configure your system, the environment you are using
+and the test equipment. The Settings also contain all the IP addresses and port number for all the known devices,
+together with other static information like the device name, default settings for the device like speed, timeout, delay
+time, firmware version, etc. We will go into more details about the content later, let’s now first look at the format
+and usage of the Settings.
+
+## Loading the Settings
+
+The Settings can be loaded as follows:
+
+```python
+>>> from egse.settings import Settings
+>>> settings = Settings.load()
+```
+
+The `settings` object will be a dictionary where the keys are the top-level groups that are defined in the settings
+for each package. For a system that has only `cgse-common` and `cgse-core` installed, the `settings` will contain
+something like this:
+
+```text
+>>> print(settings)
+Settings
+├── PACKAGES
+│   ├── CGSE_COMMON: Common classes, functions, decorators, etc. for the CGSE
+│   └── CGSE_CORE: The core services of the CGSE
+├── SITE
+│   ├── ID: LAB42
+│   ├── SSH_SERVER: localhost
+│   └── SSH_PORT: 22
+├── PROCESS
+│   └── METRICS_INTERVAL: 10
+├── Logging Control Server
+│   ├── PROTOCOL: tcp
+│   ├── HOSTNAME: localhost
+│   ├── LOGGING_PORT: 7000
+│   ├── COMMANDING_PORT: 7001
+│   ├── METRICS_PORT: 7003
+│   ├── MAX_NR_LOG_FILES: 20
+│   ├── MAX_SIZE_LOG_FILES: 20
+│   ├── TEXTUALOG_IP_ADDRESS: 127.0.0.1
+│   └── TEXTUALOG_LISTENING_PORT: 19996
+├── Configuration Manager Control Server
+│   ├── PROTOCOL: tcp
+│   ├── HOSTNAME: localhost
+│   ├── COMMANDING_PORT: 6000
+│   ├── MONITORING_PORT: 6001
+│   ├── SERVICE_PORT: 6002
+│   ├── METRICS_PORT: 6003
+│   ├── DELAY: 1
+│   └── STORAGE_MNEMONIC: CM
+└── Storage Control Server
+    ├── PROTOCOL: tcp
+    ├── HOSTNAME: localhost
+    ├── COMMANDING_PORT: 6100
+    ├── MONITORING_PORT: 6101
+    ├── SERVICE_PORT: 6102
+    ├── METRICS_PORT: 6103
+    └── DELAY: 1
+```
+
+If you only need the settings for a particular component, specify that group's name:
+
+```python
+>>> storage_settings = Settings.load("Storage Control Server")
+
+>>> print(storage_settings)
+Storage
+Control
+Server
+├── PROTOCOL: tcp
+├── HOSTNAME: localhost
+├── COMMANDING_PORT: 6100
+├── MONITORING_PORT: 6101
+├── SERVICE_PORT: 6102
+├── METRICS_PORT: 6103
+└── DELAY: 1
+```
+
+The values can be accessed as usual with a dictionary, by specifying the name of the parameter as the key:
+
+```python
+>>> print(storage_settings["COMMANDING_PORT"])
+6100
+```
+
+We usually only go one level deep when defining settings, and as a convenience, that first level of variables can
+also be accessed with the dot-notation.
+
+```python
+>>> print(storage_settings.COMMANDING_PORT)
+6100
+```
+
+## Entry-points
+
+The Settings are collected from a set of YAML files which are provided by the packages through the entry-point
+`cgse.settings`. The default Settings file is named `settings.yaml` but this can be changed by the entry-point (see
+below).
+
+Let's take a look at how the settings are provided for the `cgse-core` package. First, the `pyproject.toml` file of
+the project shall define the entry-point. In the snippet below, the entry-point `cgse-core` is defined for the group
+`cgse.settings`.
+
+```toml
+[project.entry-points."cgse.settings"]
+cgse-core = "cgse_core:settings.yaml"
+```
+
+The entry-point itself has the following format: `<name> = "<module>.<filename>"`, where
+
+- `<name>` is the name of the entry-point given in the `pyproject.toml` file, usually this is the package name,
+- `<module>` is a valid module name that can be imported and from which the location can be determined, and
+- `<filename>` is the name of the target file, e.g. a YAML file.
+
+!!! Note
+
+    The module name for this entry point has an underscore instead of a dash, i.e. `cgse_core` instead of 
+    `cgse-core`. The reason is that module names with a dash will generate a SyntaxError during import.
+
+The above example will load the settings for this package from the `settings.yaml` file that is located in the
+`cgse_core` module. That is, the package shall also provide this as follows:
+
+```text
+cgse-core
+├── pyproject.toml
+└── src
+    └── cgse_core
+        ├── __init__.py
+        └── settings.yaml
+```
+
+The `settigs.yaml` file for this module looks something like this:
+
+```text
+PACKAGES:
+    CGSE_CORE: The core services of the CGSE
+
+Logging Control Server:                          # LOG_CS
+
+    PROTOCOL:                       tcp
+    HOSTNAME:                 localhost          # The hostname that client shall connect to, e.g. pleiad01 @ KU Leuven
+    LOGGING_PORT:                  7000
+    COMMANDING_PORT:               7001
+    METRICS_PORT:                  7003          # The HTTP port where Prometheus will connect to for retrieving metrics
+    MAX_NR_LOG_FILES:                20          # The maximum number of log files that will be maintained in a roll-over
+    MAX_SIZE_LOG_FILES:              20          # The maximum size one log file can become
+    TEXTUALOG_IP_ADDRESS:     127.0.0.1          # The IP address of the textualog listening server
+    TEXTUALOG_LISTENING_PORT:     19996          # The port number on which the textualog server is listening
+
+Configuration Manager Control Server:            # CM_CS
+
+    ...
+```
+
+## Local Settings
+
+You can, and you should, define local settings for your project and put those settings in a known folder
+on your system. The usual place is `~/cgse/local-settings.yaml`. This file will be automatically loaded by the
+`Settings.load()` function when you define the local settings environment variable. That variable name is
+`<PROJECT>_LOCAL_SETTINGS` where `<PROJECT>` is the name of your project as defined by the `PROJECT` environment
+variable. For a `PROJECT=LAB23` the local settings would be defined as follows:
+
+```text
+$ export LAB23_LOCAL_SETTINGS=~/cgse/local-settings-lab23.yaml
+```
+
+The local settings take higher precedence that will overwrite the global settings when loaded. You only need to define
+the settings that actually change for your local installation, respect the full hierarchy when specifying those
+settings. You are allowed to define new entries at any level in the Settings hierarchy.
+
+The usual parameters to put into a local settings file are:
+
+- the SITE ID
+- the hostnames of the different devices that you use
+- the hostname of the server where core services or device control servers are running
+- port numbers that have been changed from the default
+
+## Terminal Command
+
+You can check the current settings from the terminal with the following command:
+
+```shell
+$ py -m egse.settings
+Settings
+├── PACKAGES
+│   ├── CGSE_COMMON: Common classes, functions, decorators, etc. for the CGSE
+│   └── CGSE_CORE: The core services of the CGSE
+├── SITE
+│   ├── ID: LAB42
+│   ├── SSH_SERVER: localhost
+│   └── SSH_PORT: 22
+├── PROCESS
+│   └── METRICS_INTERVAL: 10
+├── Logging Control Server
+│   ├── PROTOCOL: tcp
+│   ├── HOSTNAME: localhost
+│   ├── LOGGING_PORT: 7000
+│   ├── COMMANDING_PORT: 7001
+... ...
+└── Storage Control Server
+    ├── PROTOCOL: tcp
+    ├── HOSTNAME: localhost
+    ├── COMMANDING_PORT: 6100
+    ├── MONITORING_PORT: 6101
+    ├── SERVICE_PORT: 6102
+    ├── METRICS_PORT: 6103
+    └── DELAY: 1
+Memoized locations:
+['/Users/rik/github/cgse/libs/cgse-common/src/cgse_common/settings.yaml', '/Users/rik/github/cgse/libs/cgse-core/src/cgse_core/settings.yaml', '/Users/rik/cgse/local_settings_ariel.yaml']
+```
+
+The _memoized locations_ are the settings files that have been loaded and cached. Once the application has started and
+the settings have been loaded, they can only be reloaded by explicitly forcing a reload as follows:
+
+```python
+>>> settings = Settings.load(force=True)
+```
+
+!!! Warning
+    
+    The `force` reload does however not guarantee that the settings will propagate properly throughout the application
+    or to client apps. Settings can be saved in local variables or class instances that have no knowledge of a Settings
+    reload. So, be careful when changing your Settings. If there are parameters that change often and are not as 
+    static as thought, maybe they belong in the [Setup](./setup.md) instead of the Settings. Examples are:
+    
+    - calibration parameters
+    - SUT parameters
+    - conversion functions
+    - coordinates and reference frames
+    - models
+
+
+## The design of the `load()` method
+
+A word about the `Settings.load()` method. Depending on the parameters provided, this method either loads all 
+settings, a group of settings or just one single YAML file. We have already explained how to load a specific group 
+of settings by giving the name of the group as a parameter. When you want to load just one YAML file, you need to 
+specify its location also. When a location is given as a str or a Path, the Settings will be loaded from that file 
+only, using the default `settings.yaml` name or another name given through the `filename` argument.
+
+This can be used to e.g. load command files for a device:
+
+```python
+>>> commands = Settings.load(location="~", filename="DAQ5610.yaml")
+```
+
+The mechanism behind the `Settings.load()` method is shown in the following diagram. For simplicity, parameters are 
+not shown and only the success path is presented, not any exceptions or error handling.
+
+
+![load_methods](./images/load_methods.png)

cgse-2025.0.6/docs/libs/cgse-common/setup.md

@@ -0,0 +1 @@
+# The Setup

cgse-2025.0.6/docs/libs/cgse-coordinates/index.md

@@ -0,0 +1,2 @@
+
+# Reference Coordinates

cgse-2025.0.6/docs/libs/cgse-core/index.md

@@ -0,0 +1 @@
+# Core Services

cgse-2025.0.6/docs/libs/cgse-gui/index.md

@@ -0,0 +1 @@
+# GUI Components

cgse-2025.0.6/docs/libs/index.md

@@ -0,0 +1,11 @@
+
+# Libraries
+
+The libraries are those packages that make up the CGSE framework.
+
+The libraries are located under the `libs` folder, and we currently find the following packages there:
+
+- `cgse-common`
+- `cgse-core`
+- `cgse-coordinates`
+- `cgse-gui`

cgse-2025.0.6/docs/package_list.md

@@ -0,0 +1,16 @@
+# Packages in the CGSE
+
+The CGSE is a monorepo and consists of numerous packages. Each of these packages are individually installable from 
+PyPI. We maintain a list here with all the packages in the monorepo.
+
+| Package            | Description                                      | 
+|--------------------|--------------------------------------------------|
+| `cgse-common`      | The common code used by all other packages       |
+| `cgse-core`        | The core services                                |
+| `cgse-coordinates` | Coordinate reference Frames                      |
+| `cgse-gui`         | GUI components and styles (PyQt5)                |
+| `cgse-tools`       | Plugin that adds functions to the `cgse` command |
+| `symetrie-hexapod` | Device drivers for the Symétrie Hexapods         |
+| ` plato-fits`      | FITS driver with PLATO specific format           |
+| `plato-hdf5`       | HDF5 driver with PLATO specific format           |
+| `plato-spw`        | SpaceWire driver with PATO specific packets      | 

cgse-2025.0.6/docs/projects/cgse-tools.md

@@ -0,0 +1,2 @@
+
+# Tools for the CGSE framework

cgse-2025.0.6/docs/projects/index.md

@@ -0,0 +1,16 @@
+# Projects
+
+The projects are those packages that add functionality to the CGSE framework.
+
+The projects live under the folder `projects`, and they are organised in _generic_ and _specific_ projects. Generic 
+projects do not have an implementation that is specific for one particular project, while, obviously, specific 
+projects have. We currently have the following generic packages:
+
+- `cgse-tools`
+- `symetrie-hexapod`
+
+and then there are the project specific packages:
+
+- `plato-fits`
+- `plato-hdf5`
+- `plato-spw`

cgse-2025.0.6/docs/projects/symetrie-hexapod.md

@@ -0,0 +1,2 @@
+
+# The Symétrie Hexapods