Literal Include - #61
Conversation
Quick draft w/ Cursor on include support.
| facility_included_file.write_text(facility_included_content) | ||
| facility_nested_file.write_text(facility_nested_content) | ||
|
|
||
| data = pals.Lattice.from_file(main_file) |
There was a problem hiding this comment.
What was the intention here? Why does this go through Lattice.from_file as opposed to going through functions.load_file_to_dict as below (which would work here too - tested locally)? Could you comment on whether you wanted to expand the Lattice.from_file function but haven't gotten to implement the feature in the PR yet? I think I'm missing some context, inteded use case, and current PR progress, to start working on completing this PR.
There was a problem hiding this comment.
Do you have any info to share about the questions in my previous comment?
There was a problem hiding this comment.
Ah I thought we discussed this in person 2 weeks ago :)
from_file is the primary user-facing API users shall use, so this exercises that API.
Using both here and below just spreads the API surface coverage with minimal duplication.
There was a problem hiding this comment.
Okay, thanks. Let me know if the changes I pushed in 1b437b4 accomplish what you had in mind.
# Conflicts: # src/pals/PALS.py
Tighten the include resolution to the standard's wording (included file data is spliced verbatim at the current level of nesting): - Sub-level included files keep an extension check instead of none: the standard's .subpals inner suffix is accepted alongside .pals, anything else still errors. - Structural mismatches (a sequence included at a mapping level, a scalar at a sequence level) raise a clear error instead of being silently dropped or reshaped; the speculative list-of-one-key-dicts merge is removed. - Include cycles are detected via the chain of including files and reported, instead of recursing until the interpreter gives up. Diamond-shaped includes remain allowed. - Lattice.from_file now follows the standard's use statement: the last Lattice defined is instantiated by default and a `use` entry overrides it; documents without a facility no longer crash it. The tests use .subpals.yaml fragment names, cover the standard's element-parameter include example, relative resolution from the including file's own directory, the error paths, and the use-statement selection rules. machine/machine.pals.yaml and unit_tests/loading/include/sub/layout.pals.yaml leave the standard-examples known-failures list. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The YAML documents the include tests exercise are checked-in files under tests/pals_files (one directory per scenario) instead of literal strings written to tmp_path, mirroring how the standard organizes its examples corpus. Relative include targets now demonstrably resolve against the including file's checked-in location. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- A `use` entry naming no defined Lattice is an error in Lattice.from_file instead of a silent fall-through to the last lattice: per the standard, use overrides the default selection. PlaceholderName now records whether a reference was written as a `use:` entry, which also lets such entries keep their form when serialized instead of degrading to bare name references. - Include resolution in a full document is scoped to the PALS root node, where the standard requires include statements to live; top-level siblings of the PALS node are outside the standard and are no longer traversed (an unresolvable include there no longer errors). - Include cycle detection canonicalizes paths with realpath so a cycle routed through a directory symlink is reported as circular instead of recursing into the filesystem limit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Support for literal includes:
https://pals-project.readthedocs.io/en/latest/fundamentals.html#including-other-files-within-pals-files