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. Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.85.1 Signed-off-by: Jan Lindemann <jan@janware.com>
Release 1.0.0-262@suse-tumbleweed/x86_64
2026-09-11 11:22:33 +02:00 · 2026-09-10 23:32:02 +00:00 · 2026-09-10 23:12:01 +00:00 · 2026-09-10 23:10:51 +00:00
3 changed files with 5 additions and 5 deletions
--- a/4
+++ b/4
@ -1,4 +1,4 @@
-suse-tumbleweed/x86_64: 0ac23bf5e3b8c21775911bc8d7afc9c9
+suse-tumbleweed/x86_64: 6d39e6eb74af4b013e5b98175aea29ae
 suse-tumbleweed/i586: 86ea923ca3861900dd03d4b1da44f8b6
 debian-10/amd64: 47167eb2d7fe2d845a1b12e0702a6e9b
 suse-42.3/x86_64: bd0e29fda82e38c89d2ed6f11797ce3a
@ -7,4 +7,4 @@ debian-8/amd64: b16e55fee0967a75aa67a4d859f0455d
 ubuntu-18.04/amd64: 190b5c45953399fd93354db0621d6f5f
 debian-10/armhf: 5d92c234d483deaf44c80cad168a8d5d
 debian-2025.4/amd64: 977965179baa6fd24d0975a05d583eb6
-kali-rolling/amd64: e76880f8ee0608d4220eb77e0abddc62
+kali-rolling/amd64: 6d39e6eb74af4b013e5b98175aea29ae
--- a/4
+++ b/4
@ -1,4 +1,4 @@
-suse-tumbleweed/x86_64: 1.0.0-260
+suse-tumbleweed/x86_64: 1.0.0-262
 suse-tumbleweed/i586: 1.0.0-44
 debian-10/amd64: 1.0.0-47
 suse-42.3/x86_64: 1.0.0-48
@ -7,4 +7,4 @@ debian-8/amd64: 1.0.0-84
 ubuntu-18.04/amd64: 1.0.0-99
 debian-10/armhf: 1.0.0-102
 debian-2025.4/amd64: 1.0.0-172
-kali-rolling/amd64: 1.0.0-261
+kali-rolling/amd64: 1.0.0-262
--- a/2
+++ b/2
@ -1 +1 @@
-1.0.0-261-dev
+1.0.0-262-dev
Author	SHA1	Message	Date
Jan Lindemann	c31dfb4bbf	lib.version.Dependency: Reject unsupported spec operators All checks were successful CI / Packaging - Kali Linux (pull_request) Successful in 4m27s Details CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m54s Details CI / Packaging test (pull_request) Successful in 0s Details CI / Packaging - Kali Linux (push) Successful in 4m0s Details CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m17s Details CI / Packaging test (push) Successful in 0s Details 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>	2026-09-11 11:22:33 +02:00
DevOps	d5e09fca91	Release 1.0.0-262@suse-tumbleweed/x86_64 All checks were successful CI / Packaging - Kali Linux (push) Successful in 4m25s Details CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m38s Details CI / Packaging test (push) Successful in 0s Details	2026-09-10 23:32:02 +00:00
DevOps	150f9f1bbc	Release 1.0.0-262@kali-rolling/amd64 All checks were successful CI / Packaging - Kali Linux (push) Successful in 4m11s Details CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m37s Details CI / Packaging test (push) Successful in 0s Details Signed-off-by: janware DevOps <devops@janware.com>	2026-09-10 23:12:01 +00:00
DevOps	225b4ec456	Start version: 1.0.0-262 Signed-off-by: janware DevOps <devops@janware.com>	2026-09-10 23:10:51 +00:00