Skip to content

Auto-create raw_data_location in dynamic_data_compiler and static_table#101

Merged
nick-gorman merged 1 commit into
masterfrom
extend-raw-data-location-auto-create
May 28, 2026
Merged

Auto-create raw_data_location in dynamic_data_compiler and static_table#101
nick-gorman merged 1 commit into
masterfrom
extend-raw-data-location-auto-create

Conversation

@nick-gorman

Copy link
Copy Markdown
Member

Summary

cache_compiler already creates the cache directory if it doesn't yet exist; the other two entry points raised UserInputError. Same parameter on three sibling APIs behaving differently is real API friction — every new user has to mkdir separately before their first dynamic_data_compiler call, and the inconsistency is unexplained.

This PR lifts cache_compiler's pattern (including the better "exists as a file, not a directory" error wording it already had) into a shared _validate_raw_data_location helper called from all three entry points.

Behaviour now consistent across dynamic_data_compiler, cache_compiler, and static_table:

raw_data_location value Result
None UserInputError("...is None")
path exists as a file UserInputError("...exists as a file, not a directory")
path doesn't exist os.makedirs(path)
path exists as a directory no-op

Why

  • First-run UX. New users shouldn't need a mkdir step before their first NEMOSIS call.
  • API consistency. Same kwarg name on three sibling functions should mean the same thing.
  • Error-quality net positive. dynamic_data_compiler and static_table previously gave a worse error when the path was a file (collapsed into "does not exist"); the shared helper fixes that.
  • Closes the release-notes overclaim — the "raw_data_cache is auto-created" bullet was previously only true for cache_compiler.

Trade-off considered: typo silence

Auto-create means a typo like nem_cahce silently creates a new empty dir at the typo location rather than raising — the user wonders why their first download is slow. The countervailing cost is forcing every user to mkdir once. Typos are rare and trivially recoverable (re-run with the correct path); the mkdir tax hits every new install. The trade-off favours auto-create, and that's already the established behaviour in cache_compiler.

Tests

  • Drop the two *_missing_includes_path_in_error tests on dynamic/static (asserted the now-obsolete raise-on-missing behaviour).
  • Add *_is_a_file and *_missing_is_auto_created for all three entry points (6 new tests; cache_compiler now has explicit coverage of the file-vs-dir distinction it already implemented).

Test plan

  • uv run pytest tests/439 passed, 1 skipped (was 433 + 1 on master pre-change; net +6 from the new tests).

🤖 Generated with Claude Code

`cache_compiler` already created the cache directory if it didn't yet
exist; the other two entry points raised `UserInputError`. Same parameter
on three sibling APIs behaving differently is API friction: every new
user has to run a separate `mkdir` for their first `dynamic_data_compiler`
call, and the inconsistency is unexplained.

Lift `cache_compiler`'s pattern (including the nicer "exists as a file,
not a directory" error message it already had) into a shared
`_validate_raw_data_location` helper called from all three entry points.

Behaviour matrix now consistent across `dynamic_data_compiler`,
`cache_compiler`, and `static_table`:

  None              -> UserInputError("...is None")
  path is a file    -> UserInputError("...exists as a file, not a directory")
  path doesn't exist -> _os.makedirs(path)
  path exists as dir -> no-op

Tests:
- Drop the two `*_missing_includes_path_in_error` tests on dynamic/static
  (they asserted the now-obsolete raise-on-missing behaviour).
- Add `*_is_a_file` and `*_missing_is_auto_created` for all three entry
  points (6 new tests; cache_compiler now has explicit coverage of the
  file-vs-dir distinction it already implemented).

Closes the "raw_data_cache is auto-created if missing" release-notes
bullet, which was previously only true for `cache_compiler`.
@nick-gorman nick-gorman merged commit 8e6c006 into master May 28, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant