Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

PyPI PyPI - Python Version codecov Ruff Checked with mypy License

redsun

A component-based, customizable application framework for scientific hardware orchestration, based on the Bluesky framework.

[!NOTE] redsun is slowly reaching maturity, enough that it is safe to start being deployed. Still, expect major breaking changes as the API crystallizes.

Problem statement

In scientific research involving device control, one of the major problems is orchestrating different hardware units to achieve reusable, reliable and documentable workflows. On top of that, such hardware orchestration should provide a coherent and understandable user interface that less technical inclined users are able to understand and leverage accurately.

This proves challenging, because making experiments is a fluid endevour. It's hard (next to impossible) to predict what are the actual final requirements a software should encapsulate, especially if the final output is to face this to scientists with no engineering background.

Rather than trying to ship an entire software on its own, redsun follows the idea of component-based development: ship off-the-shelf components, assemble and wire them depending on the needs.

Component-based development (CBD)

In CBD, interfaces are key. Each component express what it requires to be built, as well as offering functionalities that can be leveraged by other components.

Components are wrapped into an AppContainer that takes care of bootstrapping the actual application for you, letting you focus on what each component should deliver.

from mylab.devices import MyMotor
from mylab.presenters import MyController
from mylab.views import MyView

from redsun.containers import declare_device, declare_presenter, declare_view
from redsun.qt import QtAppContainer


class MyApp(QtAppContainer):
    stage = declare_device(MyMotor, axis=["X", "Y"], egu="mm")
    ctrl = declare_presenter(MyController, timeout=2.0)
    panel = declare_view(MyView)

    def wire(self) -> None:
        self.connect(self.ctrl.sig_position_changed, self.panel.update_position)


MyApp(session="my-session").run()

Each component is declared once, with the arguments it needs. wire says which signal reaches which method; the container builds everything in dependency order and connects it.

redsun provides the common glue code that each component can use to ship entire applications or single, reusable components. Leveraging Python entry points, an application can also be shipped as a single YAML configuration file, provided that different contributing components expose a redsun.yaml manifest.

So the same application can be expressed as:

# session.yaml
schema_version: 1.0
frontend: pyqt
session: my-session

devices:
  stage:
    plugin_name: mylab
    plugin_id: my_motor
    axis: ["X", "Y"]
    egu: mm

presenters:
  ctrl:
    plugin_name: mylab
    plugin_id: my_controller
    timeout: 2.0

views:
  panel:
    plugin_name: mylab
    plugin_id: my_view

wiring:
  - from: ctrl.sig_position_changed
    to: panel.update_position

plugin_id is resolved through the manifest the contributing package ships:

# mylab/redsun.yaml
devices:
  my_motor: mylab.devices:MyMotor
presenters:
  my_controller: mylab.presenters:MyController
views:
  my_view: mylab.views:MyView

Launch it with:

from redsun.container import AppContainer

AppContainer.from_config("session.yaml").run()

[!TIP] When launching an app container from a configuration file, make sure that your involved component packages (i.e. mylab in this example) are installed in the same environment where your AppContainer is launched.

AppContainer architecture

Each redsun container is structured as a Device-View-Presenter (DVP) application. This resembles the Model-View-Presenter (MVP) architecture, with the difference that at the lower level of the application sits the Device layer, leveraging ophyd-async, to interact with hardware components.

This is to make a clear statement: redsun is primarely about device control, and tries to do it well.

Documentation

See the documentation for more informations.

License

redsun is released under license Apache 2.0.

See the license for further details.

Release files for redsun 0.13.0rc0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for redsun 0.13.0rc0
File Size Uploaded
redsun-0.13.0rc0.tar.gz 99.1 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for redsun 0.13.0rc0
File Interpreter ABI Platform
redsun-0.13.0rc0-py3-none-any.whl Python 3 none any Details

Total release size: 215.1 kB

Release files / redsun-0.13.0rc0.tar.gz

Download URL redsun-0.13.0rc0.tar.gz
Size 99.1 kB
Tags Source
SHA-256 checksum
How to use checksums
ebb4eb05f52da1bd8ead4b171e5d7e408f221a7685b6ae9638f35d8d9c91b711
BLAKE2b-256 checksum
How to use checksums
f413fc4e731d4b0ee497f28c56f9e83823f41e09373c1f5befe72f07e641ff2d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 14, 2026.

Transparency log

Release files / redsun-0.13.0rc0-py3-none-any.whl

Download URL redsun-0.13.0rc0-py3-none-any.whl
Size 115.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
7798ab42fbbf124d6f69782ba23c1dd750d0ae58020a1dcd09b98685ea20f253
BLAKE2b-256 checksum
How to use checksums
e4fc098d68b5599675b527c23e94fa8fe4f567a7923fe53884099e249d0b3ded
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 14, 2026.

Transparency log

Release history Release notifications | RSS feed

0.13.0

2 release files

This release

0.13.0rc0 This release

2 release files

0.12.3

2 release files

0.12.0

2 release files

0.11.2

2 release files

0.11.1

2 release files

0.10.0

2 release files

0.9.1

2 release files

0.9.0

2 release files

0.8.2

2 release files

0.8.1

2 release files

0.8.0

2 release files

0.7.2

2 release files

0.7.1

2 release files

0.7.0

2 release files

0.6.2

2 release files

0.6.1

2 release files

0.6.0

2 release files

0.5.6

2 release files

0.5.5

2 release files

0.5.4

2 release files

0.5.3

2 release files

0.5.2

2 release files

0.5.1

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page