Repository navigation
Batch rename for the §5.1 generic filenames, paired with their prose edits #87
Description
This is the dedicated issue that decision D6 in QuantEcon/workspace-lectures#39 promised ("a batch rename across all five §5.1 files gets its own issue") and that the QuantEcon/workspace-lectures#42 validation confirmed had still not been filed after three separate promises. The register entry at #66 (decision 5, "the rename list for generic filenames") carries the same list; this issue is where the work gets planned and tracked.
The published tree is flat, so the key is a bare filename. From .dev/qeld/migration-catalog.md §5.1, the five names and where each now stands:
| file | origin | problem | status now |
|---|---|---|---|
fp.dta |
python.myst | two letters | already migrated and published under the generic name (Track B, D6 kept all seven names as-is; no collision today since lectures/ holds no other .dta) |
fred_data.csv |
advanced | names a source, not a dataset | not yet migrated — rename at migration |
test_pwt.csv |
programming | "test" | not yet migrated — rename at migration |
acs_data_summary.csv |
advanced | plausible but claims a whole survey | not yet migrated — rename at migration |
data.csv |
programming (about_py.md) |
referenced but never exists | nothing to rename — the dangling reference is the fix |
Two constraints the catalog already records:
- A rename breaks text qeld cannot reach. The catalog's example is
mle.md's prose namingmle/fp.dta; every rename must be paired with its prose/{download}edits in the same PR, found by grep rather than by the audit (§5.2 lists 28 prose refs, 11 naming a data file in two places). - Timing: the catalog wants this pass done before the remaining tracks migrate — that now means before Tracks C and D land their files, so the three unmigrated names arrive under their final names rather than needing a second breaking change.
For fp.dta, renaming now means a breaking URL change and a coordinated repoint wave for one file. The cheap alternative is to fold it into the Phase 4 interim→final cutover (#15), where every consumer URL changes anyway — proposed default, decide here.
Activity
mmcky commentedon Aug 17, 2026
Decision, 2026-08-17 (recording it here since this issue held the open question): the renames are deferred to phase 2. Wave C2 migrates
fred_data.csvandacs_data_summary.csvunder their current names, and this issue becomes the phase-2 rename review.dataBHS.csvjoins the list — the C2 conversion ofdataBHS.matkeeps the stem and changes only the extension, precisely so its real rename happens here alongside its wave-mates rather than naming one file well while the others wait.Supporting fact from the #96 validation: an org-wide Trees sweep (278 of 278 default branches, positive controls fired) found no same-name-different-content collision for either
fred_data.csvoracs_data_summary.csv— every org copy of the latter is the same blob — so deferring the renames introduces no ambiguity in the meantime.Land wave C2 + Track D — the four remaining static datasets (#98)
docs: close-out tidy — status, convention pointers and stale facts af…
mmcky commentedon Oct 6, 2026
Closing as not planned. The naming policy in #113 (closed 2026-09-06) settled this. All four names here (
fred_data,test_pwt,acs_data_summary,dataBHS) have consumers, so under its rule 6 they stay, andfp.dtakeeps its upstream name under rule 5. #145 removed the manifest comments that still pointed here as pending work.As #113 says, this issue remains the record of the names that would be dual-served under a new key if a second consumer ever arrives. Reopen it then.