Open llucax opened 5 months ago
I like frequenz.actor.base
, because it is the base class for all actors. but works badly for namespaced imports from frequenz.actor import base
.
Maybe frequenz.actor.actor_base
?
Maybe, what about frequenz.actor.actor
? It is a bit redundant but it should work more naturally with the imports.
I will try if there is any way to still use the frequenz.actor
module, that is definitely the ideal, but I don´t have very high expectations to succeed.
it would be actor inception 3 levels deep:
from frequenz.actor import actor
class A(actor.Actor):
I just did a test and we can use frequenz.actor
:tada:
As long as only one wheel is defining frequenz/actor/__init__.py
it seems to be fine.
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:frequenz.actor
would be the natural choice, but it is still a namespace for the many actor packages.frequenz.actor.core
orfrequenz.actor.base
might be some options, although not that clear. Keepingfrequenz.sdk.actor
could be another option, but we need to see if it doesn't conflict withfrequenz.sdk
living 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.actor
andfrequenz.actors
packages.~ We can use thefrequenz.actor
package.frequenz-actor-python
~frequenz-core-python
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.