What's needed?
We need to allow cloud applications to be able to write actors without depending on the microgrid.
Proposed solution
Split the frequenz.sdk.actor package to its own repository:
Use cases
All the cloud apps.
Alternatives and workarounds
For now we've been copying protobuf files from the common API repo to the API repos that should depend on common to break the dependency, but this is clearly not sustainable.
Additional context
This is a very complicated, multi-dimensional, problem, involving many parts. Is part (and one way) to solve the dependency conflict of the SDK depending on the microgrid API v0.15 (and common v0.4) and the new API clients depending on common v0.5.
What's needed?
We need to allow cloud applications to be able to write actors without depending on the microgrid.
Proposed solution
Split the
frequenz.sdk.actorpackage to its own repository:frequenz.actorpackage.See which namespace would be possible to use for the new python package:frequenz.actorwould be the natural choice, but it is still a namespace for the many actor packages.frequenz.actor.coreorfrequenz.actor.basemight be some options, although not that clear. Keepingfrequenz.sdk.actorcould be another option, but we need to see if it doesn't conflict withfrequenz.sdkliving in another package too. Another alternative could befrequenz.actors(in plural, as we already have withchannels), but that might be a bit confusing that we have bothfrequenz.actorandfrequenz.actorspackages.frequenz-actor-pythonUse cases
All the cloud apps.
Alternatives and workarounds
For now we've been copying protobuf files from the common API repo to the API repos that should depend on common to break the dependency, but this is clearly not sustainable.
Additional context
This is a very complicated, multi-dimensional, problem, involving many parts. Is part (and one way) to solve the dependency conflict of the SDK depending on the microgrid API v0.15 (and common v0.4) and the new API clients depending on common v0.5.