make rclomatic pythantic #10

New issue

Open

opened 2026-08-05 09:49:19 +00:00 by mich · 1 comment

mich commented

2026-08-05 09:49:19 +00:00

Owner

rclomatic is at the moment pure functional programming. Make it more pythantic by wrapping zfs, btrf, ... in classes.

mich added the

todo

label

2026-08-05 09:49:19 +00:00

mich commented

2026-08-05 11:47:58 +00:00

Author

Owner

Done (merged to dev, commits 7e25722..cbc395d):

Replaced the ZFS/BTRFS type-tag dispatch (resolve_snapshot_backend() returning (\"zfs\"|\"btrfs\"|None, cfg) with every caller branching on the string) with a SnapshotBackend interface (backend.py) and ZfsBackend/BtrfsBackend classes implementing it.
config.resolve_snapshot_backend() is now a factory returning an instantiated backend (or None) instead of a tuple.
sync.py and actions/list_cmd.py now call backend.resolve_source_dir(...)/backend.list_snapshots(...) polymorphically — every if backend == \"zfs\": ... elif ... branch is gone.
actions/check.py needed zero changes.
Low-level subprocess-wrapping helpers that don't need instance state (resolve_dataset, replace_snapshot, create_snapshot, resolve_location_dir) stayed as plain functions rather than being forced onto a class.
No behavior change: verified by running the CLI side-by-side (old vs. new) across every backend mode and config shape, with byte-identical stdout/stderr/log output, plus confirming check still never mutates a create: true target's snapshot. Full test suite green (193 tests, up from 190).
Also fixed a leftover stale comment in deploy/config/rclomatic.d/example.yaml.example referencing the old resolve_zfs_source() name.

Design/plan docs: docs/superpowers/specs/2026-08-05-rclomatic-oop-snapshot-backends-design.md, docs/superpowers/plans/2026-08-05-rclomatic-oop-snapshot-backends.md.

Open / explicitly out of scope:

hooks.py, ntfy.py, stats.py, and the other non-backend modules were not converted to classes. This work was scoped to the one place in the codebase with real multi-implementation type-tag dispatch to replace (ZFS vs. BTRFS snapshot backends) — the other modules don't have an equivalent pattern, so wrapping them in classes would be decorative rather than fixing anything. If the "..." in the issue title meant other modules should also become class-based, that's a separate follow-up, not covered here.
Not pushed to origin yet — only merged locally into dev.

**Done** (merged to `dev`, commits `7e25722`..`cbc395d`): - Replaced the ZFS/BTRFS type-tag dispatch (`resolve_snapshot_backend()` returning `(\"zfs\"|\"btrfs\"|None, cfg)` with every caller branching on the string) with a `SnapshotBackend` interface (`backend.py`) and `ZfsBackend`/`BtrfsBackend` classes implementing it. - `config.resolve_snapshot_backend()` is now a factory returning an instantiated backend (or `None`) instead of a tuple. - `sync.py` and `actions/list_cmd.py` now call `backend.resolve_source_dir(...)`/`backend.list_snapshots(...)` polymorphically — every `if backend == \"zfs\": ... elif ...` branch is gone. - `actions/check.py` needed zero changes. - Low-level subprocess-wrapping helpers that don't need instance state (`resolve_dataset`, `replace_snapshot`, `create_snapshot`, `resolve_location_dir`) stayed as plain functions rather than being forced onto a class. - No behavior change: verified by running the CLI side-by-side (old vs. new) across every backend mode and config shape, with byte-identical stdout/stderr/log output, plus confirming `check` still never mutates a `create: true` target's snapshot. Full test suite green (193 tests, up from 190). - Also fixed a leftover stale comment in `deploy/config/rclomatic.d/example.yaml.example` referencing the old `resolve_zfs_source()` name. Design/plan docs: `docs/superpowers/specs/2026-08-05-rclomatic-oop-snapshot-backends-design.md`, `docs/superpowers/plans/2026-08-05-rclomatic-oop-snapshot-backends.md`. **Open / explicitly out of scope:** - `hooks.py`, `ntfy.py`, `stats.py`, and the other non-backend modules were **not** converted to classes. This work was scoped to the one place in the codebase with real multi-implementation type-tag dispatch to replace (ZFS vs. BTRFS snapshot backends) — the other modules don't have an equivalent pattern, so wrapping them in classes would be decorative rather than fixing anything. If the \"...\" in the issue title meant other modules should also become class-based, that's a separate follow-up, not covered here. - Not pushed to `origin` yet — only merged locally into `dev`.