Accept OSI directory as the loader root#226
Conversation
When sidemantic validate or load_from_directory is pointed directly at an OSI/ directory, the JSON file sits at the loader root with no leading OSI/ path component, so the OSI-tree guard rejected it and validation reported no models. _is_under_osi_tree now also accepts an OSI-shaped JSON sitting directly in a loader root that is itself named OSI (case per the existing constant), preserving the generated-artifact exclusion and OSI-shape check.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2a07f1f00f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
When sidemantic loads an OSI/ directory directly, a document in a subdirectory of it was skipped because the guard only checked the leading relative path component. Loading the parent project accepts the same nested file (rglob + leading OSI/ check), so the two entrypoints disagreed. Treat every descendant as in the OSI tree when the loaded directory itself is named OSI.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 454c47efb9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if directory.name.casefold() == _OSI_TREE_DIR.casefold(): | ||
| return True |
There was a problem hiding this comment.
When users run the CLI from inside the OSI folder with the default path (cd project/OSI && sidemantic validate) or call load_from_directory(layer, ".") after chdiring there, directory is Path("."), whose .name is empty, so this new branch does not fire and a direct model.json is still skipped as “No models found.” Since the change is meant to accept the OSI directory itself as the loader root, check the resolved/absolute directory name rather than the raw argument.
Useful? React with 👍 / 👎.
1 participant
Follow-up to #206: when a CLI user points
sidemantic validateorload_from_directorystraight at theOSI/directory itself (the folder dbt users are told to drop released-spec OSI documents in), the JSON file sits directly at the loader root with no leadingOSI/path component.relative_partswas only('model.json',), so the OSI-tree guard returned False, the JSON was never routed toOSIAdapter, and validation reported "No models found"._is_under_osi_treenow also accepts an OSI-shaped JSON sitting directly in a loader root whose own directory name isOSI(case per the existing_OSI_TREE_DIRconstant), in addition to the existing top-levelOSI/subtree case. The generated-artifact exclusion (target/,dbt_packages/) and the OSI-shape check are unchanged, so an archived/scratch OSI document under a non-OSI folder is still ignored.Known limitation: this only matches when the loaded directory itself is literally named
OSI; an OSI document at a differently-named root (e.g.validate .from a project root with the document at top level) is still rejected, matching dbt's<project_root>/OSI/scope.