Skip to content

Latest commit

 

History

History
42 lines (37 loc) · 2 KB

File metadata and controls

42 lines (37 loc) · 2 KB

SESSION.md — encrypted-cache

Current state (2026-02-15)

What happened

  • Extracted encrypted_cache from akepylib into a standalone project.
  • Source lives in src/encrypted_cache/core.py, re-exported via __init__.py.
  • Removed dependency on akepylib — the get_path_relative_to_home() helper was inlined as _get_path_relative_to_home().
  • Logger name changed from "akepylib.encrypted_cache" to "encrypted_cache".
  • Repository URL updated to https://github.com/akeedev/encrypted-cache.
  • All tests, specs, docs, and notebooks copied and adapted.
  • py.typed marker added for mypy compatibility.
  • nbstripout configured for the git commit hook.

Verification

  • 42 tests pass, mypy clean, ruff clean.
  • akepylib updated to depend on this project via [tool.uv.sources] editable path — its 116 tests also pass.

Project structure

src/encrypted_cache/
    __init__.py          # re-exports EncryptedCache, SaltMismatchError, get_hashed_filename
    core.py              # main implementation
    py.typed             # PEP 561 marker
tests/
    test_rfeat_010_encrypted_cache.py
spec/
    000-overview.md
    rfeat-010-encrypted_cache.md
doc/
    encrypted_cache.md
notebooks/
    010_demo_encrypted_cache_1_nolib.ipynb   # standalone demo (no lib import)
    010_demo_encrypted_cache_2_withlib.ipynb  # demo using the library
data/                    # gitignored, runtime cache storage

Possible TODOs

  • Publish to PyPI (or a private index) so downstream projects can depend on it without local path references.
  • Add a proper README section on threat model (currently only in the spec).
  • Consider whether plistlib serialization should remain the default or if JSON should be offered as an alternative (would remove the macOS-specific dependency for cross-platform use).
  • The nolib notebook (010_demo_encrypted_cache_1_nolib.ipynb) still uses a JSON-based inner payload (not plist). Decide whether to align it with the library's plist approach or keep it as a simpler standalone example.