-
Notifications
You must be signed in to change notification settings - Fork 20
Description
To have a clean public interface we are defining some top level sub-packages that expose classes in some sub-packages or sub-modules, but some of these top-level packages have or can have cyclic dependencies. For example, with the introduction of the LogicalMeter, which uses the DataSourcingActor, we have the actor package depending on the timeseries packages and viceversa (currently we are not exposing the LogicalMeter directly in timeseries because of this.
There are 2 main paths that I can see here:
- Avoid cyclic dependencies between packages.
- Don't expose sub-modules symbols in packages (and use them instead as namespaces for other modules).
I noticed some other issues with approach 1., like in actor, it doesn't look right to expose classes supporting actor implementations (like Request / Response in PowerDistirbutingActor or ComponentMetricRequest in DataSourcingActor) and it makes sense to have a namespace for these (this is actually why the PowerDistributingActor ended up with its own sub-module).
This also can allow for shorter class names, for example: actor.power_distributing.Actor, which also plays nicely with Google coding standard (which we are supposed to be using) if we use from frequenz.sdk.actor import power_distributing; pd = power_distributing.Actor(...); pd_sender.send(power_distributing.Request(....)).
It is a bit of a drastic change, but it might make sense.
Adopting 1. might look as a less drastic change, but in reality it introduces artificial limitations in how we want to structure our API.
Coming from @leandro-lucarella-frequenz in #66 (comment)
Metadata
Metadata
Assignees
Labels
Type
Projects
Status