You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Plugins MUST support defining both a configuration object (a Pydantic model) and some `engine`-related implementation object (`ConfigurableTask`, `ColumnGenerator`, etc.).
6
+
1. The UX for making plugins discoverable MUST be simple. We should only require users define a single `Plugin` object that gets referenced in a single entry point.
7
+
1. The plugin system MUST NOT introduce a dependency chain that makes any `config` module depend on any `engine` module.
8
+
a. Breaks "slim install" support, because `engine` code may include third-party deps that a `config`-only slim install will not include.
9
+
b. Introduces a high risk of circular imports, because `engine` code depends on `config` modules.
10
+
1. A client using a slim-install of the library SHOULD be able to use plugins.
11
+
12
+
13
+
## Current state
14
+
15
+
The current plugin system violates REQ 3 (and by extension REQ 4):
One idea that was floated is to refactor existing `engine` code so that base classes exist in some "blessed" module(s) that we would ensure do not create circular imports with `config` modules,
26
+
but this seems...
27
+
- hard to enforce/guarantee
28
+
- potentially restricting (what if a plugin author wants to use objects from other parts of `engine`)
29
+
- conceptually not ideal (it's just simpler to say "`engine` can import/depend on `config`, but not vice-versa" full stop instead of carving out exceptions)
30
+
- potentially complicated with respect to however we restructure packages to support slim installs
31
+
32
+
33
+
## Idea proposed in this branch
34
+
35
+
Make the `Plugin` object "lazy" by defining the config and and task types as fully-qualified strings rather than objects.
36
+
37
+
By using strings in the `Plugin` object fields, **if** the plugin is structured with multiple files (e.g. `config.py` and `task.py`)*,
38
+
then the core library's `config` code that uses plugins (to extend discriminated union types) can load the plugin and resolve **only**
39
+
the config class type; it would not need to resolve/load/import the plugin's task-related module where `engine` base classes are imported and subclassed.
40
+
41
+
> *This multi-file setup wouldn't be **required** out of the box; see "Plugin development lifecycle" below.
42
+
43
+
Example:
44
+
```python
45
+
# src/my_plugin/config.py
46
+
from data_designer.config.column_types import SingleColumnConfig
47
+
48
+
classMyPluginConfig(SingleColumnConfig):
49
+
foo: str
50
+
51
+
52
+
53
+
# src/my_plugin/generator.py
54
+
from data_designer.engine.column_generators.generators.base import ColumnGenerator
0 commit comments