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
Copy file name to clipboardExpand all lines: docs/md/dev/models.md
+63-30Lines changed: 63 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ Model repository developers can use the `modflow-devtools` registry-creation fac
78
78
79
79
## Architecture
80
80
81
-
This will involve a few new components (e.g., bootstrap file, `MergedRegistry` class) as well as modifications to some existing components (e.g., existing registry files, `PoochRegistry`). It should be possible for the `ModelRegistry` contract to remain unchanged.
81
+
This involves several new components (bootstrap file, user config overlay) and a consolidated registry class hierarchy. The previous `ModelRegistry` ABC has been replaced with a Pydantic-based `Registry` base class that both `LocalRegistry` and `PoochRegistry` inherit from.
82
82
83
83
### Bootstrap file
84
84
@@ -121,6 +121,24 @@ refs = [
121
121
122
122
Note: The bootstrap refs list indicates default refs to sync at install time. Users can request synchronization to any valid git ref (branch, tag, or commit hash) via the CLI or API.
123
123
124
+
#### User config overlay
125
+
126
+
Users can customize or extend the bundled bootstrap configuration by creating a user config file at:
The user config follows the same format as the bundled bootstrap file. Sources defined in the user config will override or extend those in the bundled config:
131
+
- Sources with the same key will be completely replaced by the user version
132
+
- New sources will be added to the available sources
133
+
134
+
This allows users to:
135
+
- Add private or custom model repositories
136
+
- Point to forks of existing repositories
137
+
- Override default refs for existing sources
138
+
- Temporarily disable sources (by overriding with empty refs list)
139
+
140
+
The user config is automatically loaded and merged when using the default bootstrap location. For testing, a custom user config path can be specified via the `user_config_path` parameter to `load_bootstrap()`.
141
+
124
142
### Registry files
125
143
126
144
There are currently three separate registry files:
@@ -352,35 +370,34 @@ Benefits of this approach:
352
370
353
371
### Registry classes
354
372
355
-
`PoochRegistry` is currently associated with a single state of a single repository. This can continue. Introduce a few properties to (e.g. `source` and `ref`) to make the model source and version explicit.
356
-
357
-
`PoochRegistry` should be immutable — to synchronize to a new model source state, create a new one.
358
-
359
-
Introduce a `MergedRegistry` compositor to merge multiple `PoochRegistry` instances under the same `ModelRegistry` API. The initializer can simply accept a list of pre-constructed `PoochRegistry` instances, and expose a list or dictionary of the registries of which it consists. Properties inherited from `ModelRegistry` (`files`, `models`, `examples`) can return merged views.
360
-
361
-
Handle synchronization, `MergedRegistry` construction, and similar concerns at the module (i.e. higher) level. Registries don't need to concern themselves with this sort of thing.
`LocalRegistry` is unaffected by all this, as it suits a different use case largely aimed at developers. Consider renaming it e.g. to `DeveloperRegistry`.
373
+
The registry class hierarchy has been consolidated onto a Pydantic-based `Registry` base class (defined in `schema.py`):
374
+
375
+
**`Registry` (base class)**:
376
+
- Pydantic model with `files`, `models`, `examples` fields
377
+
- Optional `meta` field for registry metadata (present when loaded from TOML, None for local registries)
378
+
-`FileEntry` model supports both local (`path`) and remote (`url`) files
379
+
- Base `copy_to()` raises `NotImplementedError` - subclasses override
380
+
- Can be instantiated directly for data-only use (e.g., loading/parsing TOML files)
381
+
382
+
**`LocalRegistry`**:
383
+
- Inherits from `Registry`
384
+
- Scans local filesystem directories for models
385
+
- Creates `FileEntry` objects with `path` field
386
+
- Implements `copy_to()` for local file copying
387
+
- No `meta` field (remains None)
388
+
389
+
**`PoochRegistry`**:
390
+
- Inherits from `Registry`
391
+
- Loads from cached or bundled registry files
392
+
- Creates `FileEntry` objects with both `url` (source) and `path` (cache location)
393
+
- Implements `copy_to()` for remote fetching + copying
394
+
- Populates `meta` from registry file if available
0 commit comments