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
A one-time call at startup sets global library state; all functions then read from it. This is similar to configuration/init pattern used by logging libraries and the Sentry SDK.
* Pros: requirements #1 and #2 satisfied; typed; derivation logic lives once in the library
84
84
* Cons: requirement #3 only partially satisfied — projects must hold and thread their own `context` reference to read derived values, which doesn't fully eliminate `_constants.py`
85
85
86
-
**#5`FoundryContext.from_package()` + `set_context()` + `foundry.context` accessor (combination of #3 and #4)**
86
+
**#5`FoundryContext.from_package()` + `set_context()` + `get_context()` (combination of #3 and #4)**
87
87
88
-
Extends #4 with a `set_context()` call that stores the context as library-level state, exposed back to callers via `foundry.context`. Library functions fall back to the configured default but accept an explicit `context` override for testing.
88
+
Extends #4 with a `set_context()` call that stores the context as library-level state, retrieved via `get_context()`. Library functions fall back to the configured default but accept an explicit `context` override for testing.
`foundry.context` is typed as`FoundryContext` — sufficient for all library functions. Project code that needs access to the extended fields keeps its own reference to the concrete instance:
207
+
`get_context()` returns`FoundryContext` — sufficient for all library functions. Project code that needs access to the extended fields keeps its own reference to the concrete instance:
201
208
202
209
```python
210
+
from aignostics_foundry_core.foundry import set_context
# project code uses bridge_context directly for its own extended fields
208
217
bridge_context.tenant_id
209
218
```
@@ -212,9 +221,9 @@ This avoids module-level generics (which are awkward in Python) while keeping bo
212
221
213
222
## Consequences
214
223
215
-
-`_constants.py` is eliminated entirely across all projects; derivation logic lives once in the library and derived values are read back via `foundry.context`.
224
+
-`_constants.py` is eliminated entirely across all projects; derivation logic lives once in the library and derived values are read back via `get_context()`.
216
225
- New projects (API servers and CLI tools alike) require a single `set_context()` call and no boilerplate.
217
226
- Production call sites are clean — no context threading.
218
227
- Tests can pass a `FoundryContext` directly without touching or resetting global state.
219
228
-`SentryContext` nesting makes it clear that the mode flags are Sentry-specific and not general-purpose project metadata.
220
-
- Projects that need additional fields subclass `FoundryContext` and pass their subclass to `configure()`; they hold their own typed reference for project-specific access.
229
+
- Projects that need additional fields subclass `FoundryContext` and pass their subclass to `set_context()`; they hold their own typed reference for project-specific access.
0 commit comments