Introduce simple CLI "check" - #3
Merged
Merged
Conversation
The config file lookup ran before the KeyboardInterrupt guard, so an interrupt there printed a traceback and exited 1.
codeplain always resolves the config file, so a config.yaml in both the spec directory and the working directory is an error regardless of the flag. The flag still takes precedence over the config value.
A skip would let a broken [project.scripts] entry pass CI. Also document the two config rules the README left out: ambiguity is a usage error and the config file is read even with --template-dir.
zanjonke
requested changes
Sep 29, 2026
zanjonke
left a comment
zanjonke
left a comment
There was a problem hiding this comment.
Looks good overall. One minor request 🚀
Comment on lines
778
to
781
There was a problem hiding this comment.
the function below implements what this function already has. i think it would be better if this one is used.
process_required_modules only parsed each ancestor for its exported concepts and dropped the tree, so parse_module_chain had to run plain_file_parser again on every ancestor to validate it and keep its tree. Now process_required_modules runs the same post-parse validation on each ancestor (validate_and_marshall_module, extracted from plain_file_parser) and collects the marshalled trees; parse_module_chain returns them. Every module is read and parsed once. plain_file_parser alone now rejects an ancestor with an undefined concept, a missing linked resource, or no implementation reqs. The requires fixtures had ancestors without implementation reqs; they are fixed.
bananaplain
commented
Sep 29, 2026
| return module_name, marshalled_plain_source, required_modules | ||
|
|
||
|
|
||
| def parse_module_chain(plain_file_name: str, template_dirs: list[str]) -> list[tuple[str, dict]]: |
Collaborator
Author
There was a problem hiding this comment.
The reason for the two functions that call the same _parse_module call, with different return signatures:
parse_module_chainreturns every module's tree and the CLI (top + required).- CLI needs all the trees to load resources and
plain_file_parseronly returns the top module's tree
- CLI needs all the trees to load resources and
plain_file_parserkeeps the 3-tuple return so the contract withcodeplainholds until the upcoming refactor
The load steps in cli.py line 84, 85, remain and they're just walks over a list now - no module is actually re-read or re-parsed.
zanjonke
approved these changes
Sep 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a CLI that validates a
.plainmodule, mirroring the checkscodeplain --dry-runperforms:It parses the module and its
requireschain, loads every linked resource, and walks each FRID of the top module. Output is<file>: OKon success,Error: …on stderr otherwise.Exit codes:
0valid,1invalid spec or missing file,2usage error,130on Ctrl-C.--template-dirfalls back to thetemplate-dirkey ofconfig.yaml(or the file named by--config-name), looked up next to the spec and then in the working directory. Found in both, it is a usage error. Other config keys are ignored.Not yet ported:
---> linked resources are still resolved against the working directory rather than the spec's directory.
---> Run
checkfrom the spec's directory until that lands (separate PR)