cgse 2024.7.0__tar.gz → 2025.0.1__tar.gz

cgse-2025.0.1/.gitignore

@@ -0,0 +1,35 @@
+# 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
+
+# Packaging
+
+uv.lock

cgse-2025.0.1/NOTES.md

@@ -0,0 +1,124 @@
+# 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. 
+
+# 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
+
+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-2025.0.1/PKG-INFO

@@ -0,0 +1,38 @@
+Metadata-Version: 2.4
+Name: cgse
+Version: 2025.0.1
+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-2025.0.1/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-2025.0.1/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-2025.0.1/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-2025.0.1/libs/cgse-common/README.md

@@ -0,0 +1,39 @@
+
+![PyPI - Version](https://img.shields.io/pypi/v/cgse-common)
+![Supported OS](https://img.shields.io/badge/Supported%20OS-Linux%20%7C%20macOS-blue)
+![Python Version from PEP 621 TOML](https://img.shields.io/python/required-version-toml?tomlFilePath=https%3A%2F%2Fraw.githubusercontent.com%2FIvS-KULeuven%2Fcgse%2Frefs%2Fheads%2Fmain%2Fpyproject.toml)
+![PyPI - Wheel](https://img.shields.io/pypi/wheel/cgse-common)
+
+# Generic Functionality used in the Common-EGSE
+
+This package 'cgse-common' contains functionality that is used by all `cgse` sub-packages, but it is designed to be a stand-alone generic package that can be used also in any other project.
+
+
+## Installation
+
+Install the package using pip:
+
+    $ pip install cgse-common
+
+
+## Usage
+
+All functionality resides in the package `egse`. As an example, if you need a standard way to format your timestamp, use the `format_datetime()` function from `egse.system`:
+
+    >>> from egse.system import format_datetime
+    >>> print(format_datetime())
+    2023-10-10T08:41:51.937+0000
+
+
+## Included Functionality
+
+A non-comprehensive list of available functionality:
+
+### Functionality of General Use
+
+* **egse.bits**: contains a number of convenience functions to work with bits, bytes and integers
+* **egse.decorators**: a collection of useful decorator functions
+* **egse.reload**: a slightly better approach to reloading modules and function than the standard importlib.reload() function.
+* **egse.resource**: provides convenience functions to use resources in your code without the need to specify an absolute path
+* **egse.system**: defines convenience functions that provide information on system specific functionality like, file system interactions, timing, operating system interactions, etc.
+* **egse.version**: functionality to retrieve the package version information

cgse-2025.0.1/libs/cgse-common/pyproject.toml

@@ -0,0 +1,80 @@
+[project]
+name = "cgse-common"
+version = "2025.0.1"
+description = "Software framework to support hardware testing"
+authors = [
+    {name = "IVS KU Leuven"}
+]
+maintainers = [
+    {name = "Rik Huygen", email = "rik.huygen@kuleuven.be"},
+    {name = "Sara Regibo", email = "sara.regibo@kuleuven.be"}
+]
+readme = {"file" = "README.md", "content-type" = "text/markdown"}
+requires-python = ">=3.9"
+license = "MIT"
+keywords = [
+    "CGSE",
+    "Common-EGSE",
+    "hardware testing",
+    "software framework"
+]
+dependencies = [
+    "click>=8.1.8",
+    "deepdiff>=8.1.1",
+    "distro>=1.9.0",
+    "gitpython>=3.1.44",
+    "numpy==1.22.4",
+    "pandas>=1.5.1",
+    "pip>=24.3.1", # only used in setup
+    "prometheus-client>=0.21.1",
+    "psutil>=6.1.1",
+    "pyyaml>=6.0.2",
+    "pyzmq == 23.2.1",
+    "rich>=13.9.4",
+]
+
+[project.entry-points."cgse.version"]
+cgse-common = 'egse'
+
+[tool.pytest.ini_options]
+pythonpath = "src"
+testpaths = ["tests"]
+addopts = "-ra --cov --cov-report html"
+filterwarnings = [
+    "ignore::DeprecationWarning"
+]
+
+[tool.coverage.run]
+omit = [
+    "tests/*",
+]
+
+[tool.hatch.build.targets.sdist]
+exclude = [
+    "/tests",
+    "/pytest.ini",
+    "/.gitignore",
+    "/*poetry*",
+    "/*setuptools*",
+]
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/egse"]
+
+[tool.ruff]
+line-length = 120
+
+[tool.ruff.lint]
+extend-select = ["E", "W"]
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[dependency-groups]
+dev = [
+    "pytest>=8.3.4",
+    "pytest-cov>=6.0.0",
+    "pytest-mock>=3.14.0",
+    "ruff>=0.9.0",
+]