cgse 0.1.0__tar.gz

cgse-0.1.0/.gitignore

@@ -0,0 +1,39 @@
+# Python versions and environment
+
+__pycache__
+.python-version
+.envrc
+
+# Build systems
+
+build
+dist
+**/*.egg-info
+
+# Apple specific
+
+.DS_Store
+
+# Unit testing
+
+.pytest_cache
+.coverage
+htmlcov
+
+# Virtual environments
+
+.env
+.venv
+venv
+
+# PyCharm IDE
+
+.idea
+
+# MKDOCS documentation site
+
+/site
+
+# Packaging
+
+uv.lock

cgse-0.1.0/NOTES.md

@@ -0,0 +1,101 @@
+# The monorepo structure
+
+Currently, the structure starts with two folders in the root, i.e. `libs` and `projects`. Where _libs_ contains library type packages like common modules, small generic gui functions, reference frames, ... and _projects_ contain packages that build upon these libraries and can be device drivers or stand-alone applications.
+
+There is one package that I think doesn't fit into this picture, that is `cgse-core`. This is not a library, but a – collection of – service(s). So, we might want to add a third top-level folder `services` but I also fear that this again more complicates the monorepo.
+
+Anyway, the overall structure of the monorepo is depicted below:
+
+```
+cgse/
+│── pyproject.toml
+├── libs/
+│   ├── cgse-common/
+│   │   ├── src/
+│   │   ├── tests/
+│   │   └── pyproject.toml
+│   ├── cgse-core/
+│   ├── cgse-coordinates/
+│   └── cgse-gui/
+│
+└── projects/
+    ├── generic/
+    │   ├── cgse-tools/
+    │   └── symetrie-hexapod/
+    └── plato/
+        ├── plato-spw/
+        ├── plato-fits/
+        └── plato-hdf5/
+```
+
+We will discuss the structure of individual packages in a later section, for now let's look at the root of the monorepo. The root also contains a `pyproject.toml` file although this is not a package that will be build and published. The purpose of this root `pyproject.toml` file is to define properties that are used to build the full repo or any individual package in it. In the root folder we will also put some maintenance/management scripts to help you maintain and bump versions of the projects, build and publish all projects, create and maintain a changelog etc.
+
+# Package Structure
+
+We try to keep the package structure as standard as possible and consistent over the whole monorepo. The structure currently is as follows (example from cgse-common):
+
+```
+├── README.md
+├── dist
+│   ├── cgse_common-2023.1.4-py3-none-any.whl
+│   └── cgse_common-2023.1.4.tar.gz
+├── pyproject.toml
+├── src/
+│   └── egse/  # namespace
+│       ├── modules (*.py)
+│       └── <sub-packages>/
+└── tests/
+    ├── data
+    └── pytest modules (test_*.py)
+```
+
+Note that each library or project is a standalone Poetry package with its own `pyproject.toml` file, source code and unit tests.
+
+# Package versions
+
+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. 
+
+
+# Build and Publish
+
+Building a source distribution and a wheel for your project is as easy as running the following command:
+```
+$ pipx run build
+* Creating isolated environment: venv+pip...
+* Installing packages in isolated environment:
+  - hatchling
+* Getting build dependencies for sdist...
+* Building sdist...
+* Building wheel from sdist
+* Creating isolated environment: venv+pip...
+* Installing packages in isolated environment:
+  - hatchling
+* Getting build dependencies for wheel...
+* Building wheel...
+```
+Make sure you have updated/bumped the version number in the `pyproject.toml`. Publishing your package on PyPI needs some more preparation, since you need to prepare a token that allows you to upload your project to PyPI. Publishing itself is a peace of cake when the credentials have been configured correctly. Poetry will also automatically take the latest version to publish.
+```
+$ pipx run twine publish
+Publishing cgse-common (2023.1.5) to PyPI
+ - Uploading cgse_common-2023.1.5-py3-none-any.whl 100%
+ - Uploading cgse_common-2023.1.5.tar.gz 100%
+```
+
+# The egse namespace
+
+You might have notices that all packages in this monorepo have a `src/egse` folder in which they maintain their source code, preferably in a sub-package. Note that the `egse` folder is not a normal Python package but a namespace. There are two important facts you need to remember about namespaces:
+
+1. A namespace package **does not** contain an `__init__.py` module, never, in any of the packages in this or any other repo. If you place an `__init__.py` module in one of your `egse` package folders, you will break the namespace and therefore also the external contributions in plugins etc.
+2. A namespace package is spread out over several directories that can reside in different packages as distributed by PyPI.
+
+# Questions
+
+What is the meaning of the common egse root folder in this monorepo and when the packages are installed through PyPI?
+
+* do we still need `get_common_egse_root()`
+
+    NO, this has nothing to do with a generic common egse and also the concept of a project root folder doesn't really work for PyPI projects, especially in a monorepo. What might work in this specific case is to use the egse namespace as a root and find folders and files in the folders that make up the namespace.
+
+* what is the Projects root directory?
+
+    This folder basically contains device implementations and plugins for e.g. the storage manager.

cgse-0.1.0/PKG-INFO

@@ -0,0 +1,38 @@
+Metadata-Version: 2.4
+Name: cgse
+Version: 0.1.0
+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
+Requires-Python: >=3.9
+Requires-Dist: rich>=13.9.4
+Requires-Dist: tomlkit>=0.13.2
+Description-Content-Type: text/markdown
+
+# Common-EGSE
+
+This is a monorepo with all the code and documentation for the common egse framework.
+
+This repository is organized in two main areas, `libs` and `projects`. The `libs` folder contains library type 
+packages like common modules, small generic gui functions, reference frames, etc. and `projects` contains packages 
+that build upon these libraries and can be device drivers or stand-alone applications.
+
+In the `libs` folder, we have the following packages:
+
+- `cgse-common`: Common modules and functions for the EGSE framework.
+- `cgse-coordinates`: Coordinate systems and transformations.
+- `cgse-core`: Core services for the EGSE framework.
+- `cgse-gui`: GUI functions for the EGSE framework.
+
+The `projects` folder contains generic and project specific packages. 
+
+We have the following generic packages:
+
+- `cgse-tools`: Tools for the `cgse` command.
+- `symetrie-hexapod`: The Symétrie Hexapod drivers. We put this in the generic folder because it is a generic device driver that can be used by different projects.
+
+We have the following project specific packages:
+
+- `plato-spw`: The PLATO SpaceWire drivers.
+- `plato-fits`: The PLATO FITS plugins.
+- `plato-hdf5`: The PLATO HDF5 plugins.

cgse-0.1.0/README.md

@@ -0,0 +1,27 @@
+# Common-EGSE
+
+This is a monorepo with all the code and documentation for the common egse framework.
+
+This repository is organized in two main areas, `libs` and `projects`. The `libs` folder contains library type 
+packages like common modules, small generic gui functions, reference frames, etc. and `projects` contains packages 
+that build upon these libraries and can be device drivers or stand-alone applications.
+
+In the `libs` folder, we have the following packages:
+
+- `cgse-common`: Common modules and functions for the EGSE framework.
+- `cgse-coordinates`: Coordinate systems and transformations.
+- `cgse-core`: Core services for the EGSE framework.
+- `cgse-gui`: GUI functions for the EGSE framework.
+
+The `projects` folder contains generic and project specific packages. 
+
+We have the following generic packages:
+
+- `cgse-tools`: Tools for the `cgse` command.
+- `symetrie-hexapod`: The Symétrie Hexapod drivers. We put this in the generic folder because it is a generic device driver that can be used by different projects.
+
+We have the following project specific packages:
+
+- `plato-spw`: The PLATO SpaceWire drivers.
+- `plato-fits`: The PLATO FITS plugins.
+- `plato-hdf5`: The PLATO HDF5 plugins.

cgse-0.1.0/TODO.md

@@ -0,0 +1,3 @@
+# TODO
+
+* [x] we will use one global version for the monorepo -> create a bump script that updates all version numbers from the master pyproject.toml

cgse-0.1.0/bump.py

@@ -0,0 +1,85 @@
+"""
+This script bumps the version of all libs and projects in this monorepo to the version that
+is currently in the `pyproject.toml` file in the root folder of the monorepo.
+
+Usage:
+    $ python bump.py
+
+Note:
+    You are expected to be in the minimal virtual environment associated with this monorepo,
+    being a `pyenv` or Poetry environment, or your global environment shall include the tomlkit
+    and the rich package.
+
+"""
+
+# /// script
+# requires-python = ">=3.9"
+# dependencies = [
+#   "tomlkit",
+#   "rich",
+# ]
+# ///
+import os
+import pathlib
+
+import rich
+import tomlkit
+import tomlkit.exceptions
+
+
+def get_master_version(master_pyproject_path):
+    """Returns the version number of the master project, i.e. cgse."""
+
+    with open(master_pyproject_path, "r") as file:
+        data = tomlkit.parse(file.read())
+
+    return data["project"]["version"]
+
+
+def update_project_version(project_dir, new_version):
+    """Updates the version of the subproject."""
+
+    os.chdir(project_dir)
+
+    # Check if the Poetry version is defined, otherwise print a message.
+
+    with open("pyproject.toml", "r") as file:
+        data = tomlkit.parse(file.read())
+
+    try:
+        data["project"]["version"] = new_version
+
+        with open("pyproject.toml", "w") as file:
+            tomlkit.dump(data, file)
+
+    except tomlkit.exceptions.NonExistentKey:
+        rich.print(f"[red]\[project.version] is not defined in pyproject.toml in {project_dir}[/]")
+
+
+def update_all_projects_in_monorepo(root_dir):
+    """Updates all pyproject.toml files with the master version number."""
+
+    excluded_subdirs = ["__pycache__", ".venv", ".git", ".idea", "cgse/build", "cgse/dist"]
+
+    master_version = get_master_version(os.path.join(root_dir, "pyproject.toml"))
+
+    rich.print(f"Projects will be bumped to version {master_version}")
+
+    for subdir, dirs, files in os.walk(root_dir):
+        if subdir == "." or subdir == ".." or any(excluded in subdir for excluded in excluded_subdirs):
+            # rich.print(f"rejected {subdir = }")
+            continue
+        if "pyproject.toml" in files and subdir != str(root_dir):  # Skip the master pyproject.toml
+            print(f"Updating version for project in {subdir}")
+            update_project_version(subdir, master_version)
+
+
+if __name__ == "__main__":
+    monorepo_root = pathlib.Path(__file__).parent.resolve()
+
+    cwd = os.getcwd()
+    os.chdir(monorepo_root)
+
+    update_all_projects_in_monorepo(monorepo_root)
+
+    os.chdir(cwd)

cgse-0.1.0/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-0.1.0/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-0.1.0/docs/dev_guide/coding_style.md

@@ -0,0 +1,95 @@
+# Style Guide
+
+This part of the developer guide contains instructions for coding styles that are adopted for this project.
+
+The style guide that we use for this project is [PEP8](https://www.python.org/dev/peps/pep-0008/). This is the standard for Python code and all IDEs, parsers and code formatters understand and work with this standard. PEP8 leaves room for project specific styles. A good style guide that we can follow is the [Google Style Guide](https://google.github.io/styleguide/pyguide.html).
+
+The following sections will give the most used conventions with a few examples of good and bad.
+
+## TL;DR
+
+| Type | Style | Example |
+|------|-------|---------|
+| Classes | CapWords | ProcessManager, ImageViewer, CommandList, Observation, MetaData |
+| Methods & Functions | lowercase with underscores | get_value, set_mask, create_image |
+| Variables | lowercase with underscores | key, last_value, model, index, user_info |
+| Constants | UPPERCASE with underscores | MAX_LINES, BLACK, COMMANDING_PORT |
+| Modules & packages | lowercase **no** underscores | dataset, commanding, multiprocessing |
+
+## General
+
+* Name the class or variable or function with what it is, what it does or what it contains. A variable named `user_list` might look good at first, but what if at some point you want to change the list to a set so it can not contain duplicates. Are you going to rename everything into `user_set` or would `user_info` be a better name?
+* Never use dashes in any name, they will raise a `SyntaxError: invalid syntax`.
+* We introduce a number of relaxations to not break backward compatibility for the sake of a naming convention. As described in [A Foolish Consistency is the Hobgoblin of Little Minds](https://legacy.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds): _Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important. [...] do not break backwards compatibility just to comply with this PEP!_
+
+## Classes
+
+Always use CamelCase (Python uses CapWords) for class names. When using acronyms, keep them all UPPER case.
+
+* Class names should be nouns, like Observation
+* Make sure to name classes distinctively
+* Stick to one word for a concept when naming classes, i.e. words like `Manager` or `Controller` or `Organizer` all mean similar things. Choose one word for the concept and stick to it.
+* If a word is already part of a package or module, don't use the same word in the class name again.
+
+Good names are: `Observation`, `CalibrationFile`, `MetaData`, `Message`, `ReferenceFrame`, `URLParser`.
+
+## Methods and Functions
+
+A function or a method does something (and should only do one thing, SRP=Single Responsibility Principle), it is an action, so the name should reflect that action.
+
+Always use lowercase words separated with underscores.
+
+Good names are: `get_time_in_ms()`, `get_commanding_port()`, `is_connected()`, `parse_time()`, `setup_mask()`.
+
+When working with legacy code or code from another project, names may be in camelCase (with the first letter a lower case letter). So we can in this case use also `getCommandPort()` or `isConnected()` as method and function names.
+
+## Variables
+
+Use the same naming convention as functions and methods, i.e. lowercase with underscores.
+
+Good names are: `key`, `value`, `user_info`, `model`, `last_value`
+
+Bad names: `NSegments`, `outNoise`
+
+Take care not to use builtins: `list`, `type`, `filter`, `lambda`, `map`, `dict`, ...
+
+Private variables (for classes) start with an underscore: `_name` or `_total_n_args`.
+
+In the same spirit as method and function names, the variables can also be in camelCase for specific cases.
+
+## CONSTANTS
+
+Use ALL_UPPER_CASE with underscores for constants. Use constants always within a name space, not globally.
+
+Good names: `MAX_LINES`, `BLACK`, `YELLOW`, `ESL_LINK_MODE_DISABLED`
+
+## Modules and Packages
+
+Use simple words for modules, preferably just one word like `datasets` or `commanding` or `storage` or `extensions`. If two words are unavoidable, just concatenate them, like `multiprocessing` or `sampledata` or `testdata`. If needed for readability, use an underscore to separate the words, e.g. `image_analysis`.
+
+## Import Statements
+
+* Group and sort import statements
+* Never use the form `from <module> import *`
+* Always use absolute imports in scripts
+
+Be careful that you do not name any modules the same as a module in the Python standard library. This can result in strange effects and may result in an `AttributeError`. Suppose you have named a module `math` in the `egse` directory and it is imported and used further in the code as follows:
+
+```python
+from egse import math
+
+# in some expression further down the code you might use
+
+math.exp(a)
+```
+
+This will result in the following runtime error:
+
+```text
+File "some_module.py", line 8, in <module>
+  print(math.exp(a))
+AttributeError: module 'egse.math' has no attribute 'exp'
+```
+
+Of course this is an obvious example, but it might be more obscure like e.g. in this [GitHub issue](https://github.com/ParmEd/ParmEd/issues/148): 'module' 
+object has no attribute 'Cmd'.

cgse-0.1.0/docs/dev_guide/docs.md

@@ -0,0 +1,53 @@
+
+# Building the documentation
+
+- Make sure you are in a virtual environment with Python 3.10+
+- Run the `mkdocs serve` from the project root older
+- Create new pages by adding folder and Markdown files inside `docs/*`
+
+## Set up your environment
+
+I created a virtual environment using `pyenv` and when I'm working on the documentation, I start up a shell with 
+this environment. Currently, only `mkdocs` and `mkdocs-material` are needed. Of course, you need to install these 
+only once.
+
+```shell
+$ pyenv virtualenv 3.10 cgse-doc-3.10
+$ pyenv shell cgse-doc-3.10
+$ pip install --upgrade pip setuptools wheel
+$ pip install mkdocs
+$ pip install mkdocs-material
+```
+
+From this shell, navigate to the project root folder and start the _live-reload_ server of `mkdocs`.
+
+```shell
+$ cd ~/github/cgse
+$ mkdocs serve
+```
+
+Now you can update files, create new folders in `docs/*`, create new Markdown files and all changes will be reloaded 
+live in the browser.
+
+When you are ready with updating, you will need to build the site and publish it on GitHub pages:
+
+```shell
+$ mkdocs build
+$ mkdocs gh-deploy -r upstream -m "documentation update on .."
+```
+
+## Commands
+
+- `mkdocs serve` — start the live-reloading docs server
+- `mkdocs build` — build the documentation site
+- `mkdocs deploy` — publish your documentation on GitHub pages
+- `mkdocs -h` — print a help message for more options
+
+## Project layout
+
+```text
+mkdocs.yml     # the mkdocs configuration file
+docs/
+    index.md   # the documentation homepage
+    ...        # other markdown pages, image, folders, ...
+```

cgse-0.1.0/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-0.1.0/docs/dev_guide/installation.md

@@ -0,0 +1,2 @@
+
+# Installation Guide for Developers

cgse-0.1.0/docs/dev_guide/plugins.md

@@ -0,0 +1,147 @@
+# Plugins
+
+The CGSE is designed to be extensible and uses a few plugin mechanisms to extend its functionally
+with external contributions. Also within the `cgse` monorepo we use the plugin mechanism at several
+places. The following entry-points are currently defined:
+
+* `cgse.version`: Each package that provides functionality within the CGSE or adds a device driver
+  registers itself to provide version information.
+* `cgse.command.plugins`: Packages can add commands or sub-commands to the `cgse` app to manage
+  their functionality from within the `cgse` app, e.g. to start or stop the service or to report on
+  its status.
+* `cgse.settings`: Package can add their own settings.
+* `cgse.resource`: Packages can register resources.
+
+Each of the entry-points knows how to load a module or object and each entry-point group is
+connected to a specific action or plugin hook like, e.g. add a command or command group to the
+`cgse` app, add package specific settings to the global settings.
+
+## Version discovery
+
+When you write a package that you want to integrate with the CGSE, provide a `cgse.version`
+entry-point. The name of the entry-point shall match the package name and is used to read the
+version from the importlib metadata. The entry-point value is currently not used. The entry-point
+value can optionally provide additional information about the package, but that is currently not
+specified.
+
+Add the following to your `pyproject.toml` file in your project's root folder, replacing
+_package-name_ with the name of your project. You can leave the entry-point value empty since it is
+currently not used.
+
+```toml
+[project.entry-points."cgse.version"]
+package-name = ''
+```
+
+## Extending the `cgse` app
+
+### Add a Command
+
+If your package provides specific functionality that can be added as a command or a command group to
+the `cgse` app, use the `cgse.command` entry-point group. Since the `cgse` app uses
+the [Typer](https://typer.tiangolo.com) package to build its commandline interface, adding a command
+is as simple as writing a function. The function will be added to the `cgse` app using
+the `app.command()` function of `Typer`, making the function a top-level command of the `cgse`
+app. The function can be defined as a plain function or with Typer's `@app.command` decorator.
+
+In the `pyproject.toml` file of your project, add the following lines to add the CGSE command:
+
+```toml
+[project.entry-points."cgse.command"]
+name = 'module:object'
+```
+Where:
+
+- `name` is the name of the command
+- `module` is a fully qualified module name for your package, a module that can be imported
+- `object` is the name of the function that you want to add as a command
+
+As an example, for the `cgse-tools` package, the `init` command of the `cgse` app is listed in 
+the `pyproject.toml` file as follows:
+
+```toml
+[project.entry-points."cgse.command"]
+init = 'cgse_tools.cgse_commands:init'
+```
+The `init` function is defined in the `cgse_commands.py` module which is located in the 
+`cgse_tools` module in the `src` folder of the package:
+
+```text
+src
+├── cgse_tools
+│   ├── __init__.py
+│   ├── cgse_commands.py
+...
+```
+
+### Add a Command group
+
+Some commands are more complicated and define a number of sub-commands. An example is the `show` 
+command where you currently have the sub-commands `env` and `settings` 
+
+```text
+$ cgse show --help
+
+ Usage: cgse show [OPTIONS] COMMAND [ARGS]...
+
+ Show information about settings, environment, setup, ...
+
+╭─ Options ─────────────────────────────────────────────────────────────────────────────╮
+│ --help          Show this message and exit.                                           │
+╰───────────────────────────────────────────────────────────────────────────────────────╯
+╭─ Commands ────────────────────────────────────────────────────────────────────────────╮
+│ settings   Show the settings that are defined by the installed packages.              │
+│ env        Show the environment variables that are defined for the project.           │
+╰───────────────────────────────────────────────────────────────────────────────────────╯
+```
+
+The `show` command is defined as a `typer.Typer()` object where `env` and `settings` are added 
+using the decorator `@<app>.command()`.
+
+```python
+import typer
+
+show = typer.Typer(help="Show information about settings, environment, setup, ...")
+
+@show.command(name="settings")
+def show_settings():
+    ...
+
+@show.command(name="env")
+def show_env():
+    ...
+```
+
+To add this command group to the `cgse` app, the following entry was used in the `pyproject.
+toml` file of the `cgse-tools` project. Notice the `[group]` at the end of the entry which 
+indicates this is a command group instead of a single command.
+
+```toml
+[project.entry-points."cgse.command"]
+show = 'cgse_tools.cgse_commands:show[group]'
+```
+
+
+### Add a Service
+
+If your package provides a device driver or a specific service, use the `cgse.service`
+entry-point group. Service entry-points follow the same scheme as command groups, i.e. they are 
+added to the `cgse` app as a `Typer()` object. Use the following entry in your `pyproject.toml` 
+file:
+
+```toml
+[project.entry-points."cgse.service"]
+name = 'module:object'
+```
+where:
+
+- `name` is the name of the service or device driver
+- `module` is a fully qualified module name for your package, a module that can be imported
+- `object` is the name of the `Typer()` object that you want to add as a service
+
+
+## Register resources
+
+TODO: what if two packages provide a resource `icons` ?
+
+- known resources: icons, styles