Python SDK rehaul to fit blueprints

[nikolausWest]

The introduction of SDK control of the Blueprint means the introduction of a new major concept to keep track of for the user of the SDK. In addition we're currently planning on adding more logable primitives.

We will have two data stores for users to put things:

• The Entity Hierarchy database (ends up in the rrd)
• The View Hierarchy (blueprint)
  • Defaults
  • Overrides

There are some constraints but you can basically put both data and styling/config in both of these places.

We also currently mix data and styling freely in the Python SDK. There is an elegance to this since it can be hard to up-front decide what is a styling and what is data (take color for example). This is not a huge problem as long as we have a small number of primitives and only one place to put them.

In python we currently only expose high level api's like:

def log_arrow(
    entity_path: str,
    origin: Optional[npt.ArrayLike],
    vector: Optional[npt.ArrayLike] = None,
    *,
    color: Optional[Color] = None,
    label: Optional[str] = None,
    width_scale: Optional[float] = None,
    ext: Optional[Dict[str, Any]] = None,
    timeless: bool = False,
)

Here origin + vector make up the primary component, which is required, while the rest is optional.

[emilk]

We have a plan for this involving objects for datatypes, components and archetypes. It needs writing down though.

[Wumpf]

@emilk didn't we have a writeup for this somewhere on notion or is this issue now just hopelessly outdated? :)