Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improvements to the auto scoping mechanisms #163

Open
ms-lolo opened this issue May 3, 2024 · 1 comment
Open

improvements to the auto scoping mechanisms #163

ms-lolo opened this issue May 3, 2024 · 1 comment

Comments

@ms-lolo
Copy link
Collaborator

ms-lolo commented May 3, 2024

we're creating more types of data structures that act as global identifiers across the project. ServiceId, CommandId, and others need to be globally unique, so we auto-prefix them with the module path in order to guarantee uniqueness and also give log messages useful metadata that shows authors the path to the definition of a given id.

Elon pointed out that using the full module path typically includes the private module file, which makes things fragile when we move the implementation across private files. We decided the prefix should probably be the path to the nearest public package where this id object is exposed. this allows us to move the class without breaking things like serialized json that might include these id objects. it's reasonable to expect things to break when we move an id class between public packages, but that matches the expectation of any other public api change.

so instead of ServiceId("rats.pipelines._something:some-service"), we want the prefixing to be something along the lines of ServiceId("rats.pipelines:Something.some-service").

@ms-lolo
Copy link
Collaborator Author

ms-lolo commented Aug 1, 2024

used the current api for a few months and have some thoughts.

this is our current pattern for defining service ids:

from rats import apps

@apps.autoscope
class PluginServices:
    THING_ONE = ServiceId[apps.Executable]("thing-one")
    THING_TWO = ServiceId[apps.Executable]("thing-two")

but this pattern doesn't provide an obvious enough api:

  • it's not clear that i shouldn't initialize the class
  • it's not possible to put the class grouping to any real use because we can't create instances with different values
  • it's easy to accidentally mutate the global state
  • probably a few others? it feels a little too special

maybe a similar direction along these lines could work and looks less foreign to me:

from rats import apps
from typing import NamedTuple

@apps.autoscope
class PluginServices(NamedTuple):
    thing_one: ServiceId[apps.Executable]
    thing_two: ServiceId[apps.Executable]

SERVICES = PluginServices(
    thing_one=ServiceId[apps.Executable]("thing-one"),
    thing_two=ServiceId[apps.Executable]("thing-two"),
)
  • feels more natural to look at rats.pipelines.SERVICES.thing_one than rats.pipelines.PluginServices.THING_ONE
  • SERVICES is immutable and iterable
  • we can serialize the value and pass it to other parts of the system
  • we can abstract and inject different instances for testing more of our wiring logic
  • we can probably simplify apps.autoscope()

… still noodling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant