Document reading a weather file, once, for both languages - #11
Draft
samuelduchesne wants to merge 1 commit into
Draft
Document reading a weather file, once, for both languages#11samuelduchesne wants to merge 1 commit into
samuelduchesne wants to merge 1 commit into
Conversation
One page, prose written once, code varying by language, filed as a how-to beside its siblings in `weather/`. Nothing about reading an EPW differs between the two libraries in a way that needs different explanation: the retrieval before it does, and the page says so and links to where that is explained. It declares `weather-file-reading` through the parity macro, so the build fails if the capability resolves to nothing. It records the decision against a public summary reader where a reader would look for one, rather than leaving them to conclude it was overlooked: the `.stat` member is a report written for a person, in around forty section shapes whose set varies with the station's climate, every figure of which is derivable from the EPW itself. It is read in one place, as the conformance corpus's oracle, where a brittle parse is an offline maintenance task rather than something in a caller's path. BLOCKED UNTIL THE PINS MOVE, on exactly three things and nothing else: the parity macro cannot resolve `weather-file-reading` at governance-2026.14, the vendored TypeScript snippets are not in docs-2026.3, and the Python snippets call functions idfkit==1.0.0-rc.3 does not have. All three clear with the pin bump that follows the release, which is where `weather/station-search.md` is already waiting.
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
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.
One page, prose written once, code varying by language, filed as a how-to beside its siblings in
weather/. Nothing about reading an EPW differs between the two libraries in a way that needs different explanation: the retrieval before it does, and the page says so and links to where that is explained.Stacked on #10, which carries the climate-zone snippet. Base it on
mainonce that merges.Draft, and red on purpose. The build fails on exactly three things and nothing else, all of them pins rather than prose:
parity("weather-file-reading")does not resolve atgovernance-2026.14. The row is in idfkit-conformance#8.docs/snippets/js/weather/reading/{read_an_epw,absent_values}.tsare not indocs-2026.3. They are authored in idfkit-js#55, becausedocs/snippets/js/is vendored andsync_js_artifacts.py --checkrejects a file present only in the vendored copy.parse_epwandmonthly_means, whichidfkit==1.0.0-rc.3does not have. They are in idfkit#204.All three clear with one pin bump after the two libraries release — the same bump #10 is already waiting on. Verified locally with both documented overrides (
sync_js_artifacts.py --from-siblingandIDFKIT_GOVERNANCE_DIR): the page renders with noERROR, both language tabs, and the parity block.What the page does
It records a decision where a reader would look for it
FR-024: there is no public summary reader, and the page says so rather than leaving a reader to conclude it was overlooked. The
.statmember is a report written for a person, in around forty section shapes whose set varies with the station's climate, and every figure in it is derivable from the EPW itself. It is read in exactly one place — as the conformance corpus's oracle — where a brittle parse is an offline maintenance task rather than something in a caller's path.Checks
check-page-kindsandcheck-capabilitiesboth pass. The 109cairosvgwarnings in a local strict build are the social plugin wanting libcairo on this machine and are identical with and without this change.