-
Notifications
You must be signed in to change notification settings - Fork 21
Split the frequenz.sdk.actor package to its own repository #851
Copy link
Copy link
Open
Labels
part:actorAffects an actor ot the actors utilities (decorator, etc.)Affects an actor ot the actors utilities (decorator, etc.)priority:highAddress this as soon as possibleAddress this as soon as possiblescope:breaking-changeBreaking change, users will need to update their codeBreaking change, users will need to update their codetype:enhancementNew feature or enhancement visitble to usersNew feature or enhancement visitble to users
Milestone
Metadata
Metadata
Assignees
Labels
part:actorAffects an actor ot the actors utilities (decorator, etc.)Affects an actor ot the actors utilities (decorator, etc.)priority:highAddress this as soon as possibleAddress this as soon as possiblescope:breaking-changeBreaking change, users will need to update their codeBreaking change, users will need to update their codetype:enhancementNew feature or enhancement visitble to usersNew feature or enhancement visitble to users
Type
Projects
Status
In progress
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.