lib.version.Dependency: Reject unsupported spec operators #95
Loading…
Reference in a new issue
No description provided.
Delete branch "jan/feature/20260911-lib-version-dependency-reject-unsupported-spec-operators"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
lib.version.Dependency: Reject unsupported spec operators
The spec split pattern ([=><]+) tokenizes only the =, > and < characters, so a PEP 440 operator like
= or != leaves its ~ or ! glued to the package name: Dependency('pkg=1.0') parses to base name 'pkg~' with operator '='. App.__get_project_refs() carries the same pattern inline, so the same specs corrupt the module name used for the -devel subpackage check. The split also tolerates operator strings the language does not support, most visibly ==, which parses and renders but raises NotImplementedError only when expansion is requested.The spec language supports exactly =, <, <=, > and >=, and boundary expansion implements all of them. Extend the split pattern with ~ and ! so that foreign operators tokenize as operator strings, and reject every operator outside the supported set in Dependency.__parsed_spec() with Dependency.Error, naming the supported operators. Route App.__get_project_refs() through Dependency for the name and module parts instead of the second inline split, so the validation lives in one place. The catch all in Dependency.__version_boundaries() stays as a backstop against drift between the allow list and the expansion cases.
The tests drop == from the accepted operator loop, drop the now-unreachable not-expandable case, and assert that ~=, !=, ~, ==, ===, << and >> are rejected at parse time with a message naming the operator.
The spec split pattern ([=><]+) tokenizes only the =, > and < characters, so a PEP 440 operator like ~= or != leaves its ~ or ! glued to the package name: Dependency('pkg~=1.0') parses to base name 'pkg~' with operator '='. App.__get_project_refs() carries the same pattern inline, so the same specs corrupt the module name used for the -devel subpackage check. The split also tolerates operator strings the language does not support, most visibly ==, which parses and renders but raises NotImplementedError only when expansion is requested. The spec language supports exactly =, <, <=, > and >=, and boundary expansion implements all of them. Extend the split pattern with ~ and ! so that foreign operators tokenize as operator strings, and reject every operator outside the supported set in Dependency.__parsed_spec() with Dependency.Error, naming the supported operators. Route App.__get_project_refs() through Dependency for the name and module parts instead of the second inline split, so the validation lives in one place. The catch all in Dependency.__version_boundaries() stays as a backstop against drift between the allow list and the expansion cases. The tests drop == from the accepted operator loop, drop the now-unreachable not-expandable case, and assert that ~=, !=, ~, ==, ===, << and >> are rejected at parse time with a message naming the operator. Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.85.1 Signed-off-by: Jan Lindemann <jan@janware.com>8c1e37500bc31dfb4bbf