rel_path is part of the API contract — test_rel_path_api_parity.py exists to hold it — and on Windows it is built from os.path.relpath, which returns backslash-separated paths.
The chain. _enrich_with_rel_path() (palinode/api/search_helpers.py) is what attaches rel_path to search, associative, dedup-suggest, orphan-repair and topic-coverage results. It calls to_rel_path() (palinode/core/path_guard.py), whose body is os.path.relpath(file_path, base). That is correct POSIX behaviour and correct Windows behaviour — it is just not the same string, and as_posix() appears nowhere in the package.
Seven test_rel_path_api_parity tests fail on native Windows in @Kaap10's 3.12 inventory and @kevin-lozada-santos's 3.11 inventory, both posted on #169. Whether all seven trace to this expression is for the fix to establish — that has not been verified, and it should not be assumed.
A separate, smaller instance in the same family. palinode/core/store.py derives a path for associative results with fp.replace(config.memory_dir + "/", "").lstrip("/") — a hardcoded separator. On Windows that replace never matches, so the value stays absolute. It feeds the result's category field, not rel_path, so the consequence is a wrong category rather than a broken contract. Worth fixing in the same pass; worth not conflating with the above.
The precedent is already in the tree. palinode/core/skip_dirs.py does rel_path.replace(os.sep, "/"). Someone solved this once, in one place, and it was never generalised.
What is wanted: rel_path renders in POSIX form on every platform, and a test that pins it so the next refactor cannot quietly undo it. Where the normalisation belongs — inside to_rel_path, or at the enrichment boundary — is a design call worth stating in the PR.
Not in scope: the rest of the Windows suite failures. Those are being carved separately.
Context: found by @Kaap10 and @kevin-lozada-santos during the native Windows runs on #169.
Reserved for @Kaap10, who claimed this slice on #169. GitHub currently rejects the direct assignment on this new issue; it is not open for another claim.
rel_pathis part of the API contract —test_rel_path_api_parity.pyexists to hold it — and on Windows it is built fromos.path.relpath, which returns backslash-separated paths.The chain.
_enrich_with_rel_path()(palinode/api/search_helpers.py) is what attachesrel_pathto search, associative, dedup-suggest, orphan-repair and topic-coverage results. It callsto_rel_path()(palinode/core/path_guard.py), whose body isos.path.relpath(file_path, base). That is correct POSIX behaviour and correct Windows behaviour — it is just not the same string, andas_posix()appears nowhere in the package.Seven
test_rel_path_api_paritytests fail on native Windows in @Kaap10's 3.12 inventory and @kevin-lozada-santos's 3.11 inventory, both posted on #169. Whether all seven trace to this expression is for the fix to establish — that has not been verified, and it should not be assumed.A separate, smaller instance in the same family.
palinode/core/store.pyderives a path for associative results withfp.replace(config.memory_dir + "/", "").lstrip("/")— a hardcoded separator. On Windows that replace never matches, so the value stays absolute. It feeds the result'scategoryfield, notrel_path, so the consequence is a wrong category rather than a broken contract. Worth fixing in the same pass; worth not conflating with the above.The precedent is already in the tree.
palinode/core/skip_dirs.pydoesrel_path.replace(os.sep, "/"). Someone solved this once, in one place, and it was never generalised.What is wanted:
rel_pathrenders in POSIX form on every platform, and a test that pins it so the next refactor cannot quietly undo it. Where the normalisation belongs — insideto_rel_path, or at the enrichment boundary — is a design call worth stating in the PR.Not in scope: the rest of the Windows suite failures. Those are being carved separately.
Context: found by @Kaap10 and @kevin-lozada-santos during the native Windows runs on #169.
Reserved for @Kaap10, who claimed this slice on #169. GitHub currently rejects the direct assignment on this new issue; it is not open for another claim.