Commit graph jw-pkg/src
Author SHA1 Message Date
c31dfb4bbf
lib.version.Dependency: Reject unsupported spec operators
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m27s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m54s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m0s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m17s
CI / Packaging test (push) Successful in 0s
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
2ae101d93b
App.__get_project_refs(): Fix recursion stop conditions
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m30s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m37s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m10s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m34s
CI / Packaging test (push) Successful in 0s
App.__get_project_refs() recurses into the package dependency graph, but
the recursion end conditions only work well if all required packages are
present. Whether a required package is installed or not is decided upon a
wrong condition, however - existence of the project's project directory,
which may or may not be misleading for both the -devel and the -run
requirements. This can lead to various unwanted outcomes: Missing packages
happily inserted into the recursion buffer, process termination instead of
recursion stop, path lookup errors instead of a clearer "unmet dependency"
message (No project path found for module xyz, Failed to find directory of
project foo).

This commit cleanly detects if -run or -devel are installed and makes the
walk stop or raise under the appropriate conditions:

1. -run missing but required, raises unmet dependency
2. -devel missing but required, raises unmet dependency
3. -run present, no -devel required, stop recursing

Signed-off-by: Jan Lindemann <jan@janware.com>
Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.85.1
2026-09-10 13:06:05 +02:00
433fe695db
App.is_installed(): Add method
The installed state of a project is judged by the proofs of installation,
which differ per subpackage: make/project.conf in the dev tree or /opt
proves the -devel package or a buildable checkout, a VERSION file in the
project directory or /usr/share/doc/packages the -run package.

Add is_installed(), which answers the proof question for a given subpackage
by searching the per-subpackage locations.

Signed-off-by: Jan Lindemann <jan@janware.com>
Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
2026-09-10 13:06:05 +02:00
a269631e92
CmdBuild.run_make(): Skip projects without buildable dir
The iteration order contains every project the dependency walk resolved,
including projects that are only installed as -devel packages below /opt.
Running the target in such a project ran make in a read-only, source-less
directory and failed the run.

Resolve each module against the workspace root only, and skip the target
with a notice when there is no buildable project directory. Factor the skip
notice into log_skip() so the platform-exclusion path shares it.

Signed-off-by: Jan Lindemann <jan@janware.com>
Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
2026-09-10 11:44:25 +02:00
7c76abed33
App.find_dir(): Allow restricting the project roots
find_dir() and its helpers resolve a project name against the workspace
root and /opt. The build iteration needs to resolve a module against the
workspace only, to tell buildable projects apart from installed ones.

Add a projs_roots parameter to find_dir(), __find_dir() and __proj_dir()
that restricts the search to the given roots. With the parameter omitted
the previous behavior is unchanged.

Signed-off-by: Jan Lindemann <jan@janware.com>
Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
2026-09-10 11:44:25 +02:00
e94437835f
lib.pkg_relations: Beautify exceptions
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m23s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m12s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m54s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m22s
CI / Packaging test (push) Successful in 0s
In pkg_relations(), pass dependent_package to Dependency.parse_deps_spec()
for better error reporting.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-10 09:52:25 +02:00
6b13ae1212
lib.version.Dependency: Beautify exceptions
Add a dependent_package parameter to Dependency's constructor, and use it
in exceptions the class raises.
2026-09-10 09:52:13 +02:00
831cff524a lib.version: Add API docstrings
All checks were successful
CI / Packaging - Kali Linux (push) Successful in 4m4s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m9s
CI / Packaging test (push) Successful in 0s
The lib.version module carries no documentation: the Syntax, Component and
Boundary types, the Version and Dependency classes and their public methods
are bare, and the compatibility tiers the next_* stepping methods implement
are not documented anywhere.

Add docstrings: a line each for the base.py types, the compatibility
tier table in the Version class, and a short description for every
public method, with the three next_* methods citing the tier each one
steps to.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-09 15:37:50 +02:00
0c808f9383 cmds.projects.lib.pkg_relations: Integrate lib.version
- The pkg_relations() function is a horribly bad read. It contains a
  mind-bending amount of interwoven case distinctions that are not clearly
  reflected in the participating variable and function names. Much of it is
  version handling. That's intricate by nature, but much of it has now been
  implemented in the lib.version module, so moving the logic there makes
  the function a good deal more readable than before. That's most of what
  this commit does.

- Use version syntax macros from lib.version instead of
  pkg_relations-defined macros, and fix the fallout in BaseCmdPkgRelations
  and CmdCreateFile.

- Use lib.version also as a central place for dep string parsing from App.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-09 15:37:50 +02:00
c9cbef15bb lib.version: Add module to parse dependency specs
pkg_relations() parses dependency specifications such as 'foo-devel >=
1.2.3-4' with inline regular expressions and mixes the parsing with version
macro expansion and rendering in three different syntaxes.

This commit adds the lib.version module that owns the parsing of a single
specification: the base and full name and the version boundary with its
operator. Rendering happens in constraint_str() in SEM_VER, DEBIAN or
NAMES_ONLY syntax, with untemplated, include_revision, as_range,
no_subpackages and quote options. The VERSION, VERSION-REVISION and
REVISION macros are resolved through a version lookup callback,
lib.version.Version.parse_deps_spec() splits comma-separated specification
strings into Version objects, and Version breaks a version down into its
major, minor, micro and revision parts.

Unit tests cover parsing, macro resolution, rendering in all syntaxes and
the range expansion.

The module is designed to be integrated into the status quo and
intentionally does not address a couple of further TODOs. Notably
version.Syntax.SEM_VER is intended to replace
pkg_relations.VersionSyntax.SemVer, but neither are really semantic
versioning according to spec. They are close but more targeted toward RPM
and Debian package versioning. And the naming and semantics differ from
SemVer.

Naming of the four components (major and minor version) is identical,
semantic meaning aside, there's no disagreement between real SemVer,
Debian, RPM and jw-pkg. The third and fourth component deviate:

    SemVer      Debian      RPM        jw-pkg      lib.version
 3  PATCH                              RELEASE     MICRO
 4  PRERELEASE  Revision    Release    REVISION    REVISION

TODOs: RELEASE over the rest of jw-pkg needs to be adjusted by a later
commit. Syntax.SEM_VER should also be renamed, to Syntax.JW_PKG maybe,
because, as said, it's not SemVer and will probably never be - SemVer
doesn't provide the compatibility guarantees that the jw-pkg versioning
scheme offers. To be documented.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-09 15:37:50 +02:00
281a8f383e
lib.Types: Restrict LoadTypes to ABC-derived classes
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m18s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m18s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m50s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m5s
CI / Packaging test (push) Successful in 0s
The previous commit reads __abstractmethods__ via a getattr() with an empty
frozenset fallback, because in mypy 2.3.1 the scanned classes are typed as
type[object], which does not declare the attribute.

Add is_abc_class() as a TypeGuard, and skip the classes it rejects with a
debug line: LoadTypes now yields only ABC-derived classes. The guard
narrows to the classes that carry the attribute, so that the debug line can
now read __abstractmethods__ directly.

The command loaders are unaffected: every class they load is derived from
AbstractCmd, and hence from ABC. For loads that rely on the name filter
alone, plain classes are now skipped instead of being yielded.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-07 09:12:42 +02:00
ff6e13e09f
lib.Types: Read __abstractmethods__ via getattr()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m19s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m19s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m8s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m6s
CI / Packaging test (push) Successful in 0s
LoadTypes._classes() reads the __abstractmethods__ attribute of each class
that inspect.getmembers() returns for its debug output. mypy 2.2.0 allows
this, mypy 2.3.1 doesn't: It now types those classes as type[object]
instead of Any. The attribute itself is only declared on the ABCMeta
metaclass, so the direct access fails the type check.

Read the attribute through getattr() with an 'unknown' fallback string, and
annotate the variable explicitly. The runtime behavior is unchanged, since
the attribute exists whenever inspect.isabstract() is true, and the call
satisfies the checker.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: user.email <jan@janware.com>
2026-09-07 07:07:02 +02:00
994c264689
lib.ec.ssh.AsyncSSH: Actually hide password
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m18s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m20s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m50s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m20s
CI / Packaging test (push) Successful in 0s
_connect_kwargs(hide_secrets = True) is used to log the connection
parameters when a connection fails, without leaking the password. The
filtered dictionary is built before the password is replaced with
'<hidden>', and the replacement is applied to the local kwargs
dictionary afterwards, after the filtered copy has already been made.
The dictionary that ends up in the log therefore still contains the
real password.

Hide the password before building the filtered dictionary.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 20:53:33 +02:00
f6372d321a
lib.ExecContext: Fix error message in _put()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m20s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m18s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m54s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m4s
CI / Packaging test (push) Successful in 0s
_put() catches a failure of the remote command sequence and logs
"Failed to get <path> from <root>", a phrase copied over from the
get() path. This path, however, pushes content, so the message
describes the wrong operation.

Log a put-oriented message instead.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:36:46 +02:00
5230b44fa8
lib.FileContext: Interpolate path in _is_dir()
_is_dir() logs a DEBUG message when _stat() is not implemented and it
must guess from the trailing slash whether a path is a directory. The
second part of that message is a plain string rather than an f-string,
so '{path}' is logged verbatim instead of the path.

Make it an f-string so the path is interpolated.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:36:46 +02:00
e07c52eda8
lib.ExecContext: Clean up temp file in _put()
_put() writes the content into a temporary file with tee and, when
atomic is set, moves it to the target path with a final mv. The loop
over the command list sets tmp_file to None after each command, on the
assumption stated in the comment that the file has been moved at that
point - which is only true for the last command. When a chown, chmod,
or mv after the tee fails, the finally block finds tmp_file is None
and leaves the temporary file behind.

Reset tmp_file only after all commands have completed, so that the
finally block erases the temporary file whenever a step fails.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:36:46 +02:00
e6295f7d2b
lib.ec.ssh.Paramiko: Avoid recv deadlock
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m13s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m13s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m56s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m1s
CI / Packaging test (push) Successful in 0s
_run_ssh() waits for the remote process's exit status before reading
stdout and stderr. When a command produces more output than the
channel's flow-control window can hold, the server stops sending, the
remote process blocks on its write and never exits, and
recv_exit_status() blocks forever.

Drain stdout and stderr to EOF first - the channels close when the
process exits, so reading them also implies completion - and only
then query the exit status.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:00:58 +02:00
4ca370a877
lib.ec.ssh.Paramiko: Close remote stdin
_run_ssh() writes cmd_input to the remote stdin channel but never
closes the write side. The channel stays open until the client
process exits, so a remote command that reads stdin (cat, a login
shell, ...) never sees EOF and blocks forever - including for
cmd_input = None, which is supposed to mean non-interactive with
stdin from /dev/null.

Call shutdown_write() on the channel after writing the input, or
immediately when there is none, so the remote command gets EOF.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:00:58 +02:00
4b55b460ea
lib.ec.ssh.Paramiko: Pass port and password
__client() connects using only the URI's hostname and username. The
URI's port is ignored, so ssh://host:2222/... ends up connecting to
port 22, and a password carried in the URI is never passed to
paramiko, so URI-based password authentication cannot work. The Exec
and AsyncSSH clients both honor the port and the password.

Pass the port and the password to connect(). The port argument is
omitted entirely when the URI carries no port, because
getaddrinfo() would interpret a None port as service port 0; without
the argument, paramiko falls back to its default of 22.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 19:00:58 +02:00
e8ade91f21
lib.Uri: Fix path join for empty authority
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m36s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m29s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m8s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m15s
CI / Packaging test (push) Successful in 0s
__new_with_path() joins base and path with exactly one '/', assuming a
trailing '/' in base is a path separator. That assumption breaks for
URIs with empty authority, where scheme_plus_authority ends in '://'
(e.g. 'file:///tmp/x'): new_replace_path('/etc/hosts') drops the
leading slash of the path and produces 'file://etc/hosts', which
parses with hostname 'etc' and path '/hosts' instead of path
'/etc/hosts'.

Treat a base ending in '://' separately and keep a leading slash in
the path, adding one if it is missing.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 14:01:46 +02:00
a1ae17c8cb
lib.Uri: Fix __assemble(): No '://' for relative paths
Assembling a scheme-bearing form always writes '://' after the scheme, even
if the input has no authority part. For a schemeless relative path such as
'../../local/path', .full then becomes 'file://../../local/path', which
re-parses with '..' as the host and '/../local/path' as the path, both
entirely broken.

Fix __assemble() to write a bare ':' instead of '://' when the input has no
host and a relative path, so the assembled form re-parses back to the same
relative path: full of '../../local/path' is now 'file:../../local/path'.
Absolute paths and forms with an authority are unchanged.

The assembled 'file:../../local/path' form is a valid URI under the RFC
3986 generic grammar (scheme with a rootless path), while RFC 8089's file
URI ABNF admits only an empty or an absolute path. Uri thus trades RFC 8089
conformance for RFC 3986 compatibility: a relative path survives the
full-and-reparse cycle unchanged.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 14:01:46 +02:00
29abf14a67
py-ns-dir.mk: Support __init__.py generation
For in-tree tests, the jw package is split across several projects, and
each directory containing a py-ns-dir.mk contributes its subtree. So far,
it's up to that directory how the contribution is handled. Usually an
__init__.py with pkgutil.extend_path() is present in version control to
glue these parts together. This commit makes py-ns-dir.mk handle the
contribution method centrally by default unless PY_UPDATE_INIT_PY is set to
false.

As of this commit, this is the case by default, i.e. PY_UPDATE_INIT_PY is
set to false in py-ns-dir.mk, maintaining the current behaviour.

Downstream projects or modules can decide to have __init__.py centrally
maintained. For this, they need to remove __init__.py from version control
and set PY_UPDATE_INIT_PY to true in the respective Makefile.

PY_UPDATE_INIT_PY = false is also set explicitly in src/python/jw/Makefile,
because that file should never be generated. Bootstrapping the entire
workspace hinges on it.

Pending better testing, most notably of consistent in-tree testing
functionality, PY_UPDATE_INIT_PY = true might become a global default in
the future.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-09-05 13:39:51 +02:00
0407215530
init.detect_modules(): Add base_types filter
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m10s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m29s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m5s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m3s
CI / Packaging test (push) Successful in 0s
Add a parameter "base_types" to detect_modules(), defaulting to None. If
it is not None, a module is only exported if its same-named object
inherits from one of the given types. Modules without a same-named class
are skipped instead of raising AttributeError, which covers helper
modules.

The return annotation becomes Sequence[str] instead of list[str] to
remove mutability for easier type checking.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-24 14:23:27 +02:00
1385b1a4ba lib.ExecApp: Add class
All checks were successful
CI / Packaging - Kali Linux (push) Successful in 11m50s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m14s
CI / Packaging test (push) Successful in 0s
ExecApp is a ready-made base class for applications that operate
through an ExecContext: it adds the --interactive, --verbose and
--target options, exposes interactive, verbose and exec_context
properties, and closes the exec context when the async context
manager exits.

The code for that has lived in jw.pkg.App code before, which now
inherits from ExecApp.

A fix along the way: __aexit__() closes the exec context and then chains
to super().__aexit__(), so App.close() runs when the async context
manager exits. Before the change, exiting the async context left the app
unclosed; close() ran only on the run() path. Add a unit test that
builds an ExecApp with a root command and asserts that close() runs on
context exit and that the exec options are registered.

The exec options are now registered before App's own options,
which moves them up in the rendered --help output. Update the
golden file of the help integration test to match.

Signed-off-by: Jan Lindemann <jan@janware.com>
Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
2026-08-22 17:31:57 +02:00
eec9325b46
App.__format_topdir(): Mention relative in error
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 8m15s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m19s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 8m23s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m7s
CI / Packaging test (push) Successful in 0s
__format_topdir() accepts "absolute", "relative", "unaltered", and
"make:<variable-name>", but the error message it raises for anything
else only lists "unaltered", "absolute", and
"make:<variable-name>", leaving out "relative".

Add "relative" to the list of valid formats in the error message.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-22 16:25:28 +02:00
a89eb18d52 App.__find_circular_deps(): Fix cycle path
All checks were successful
CI / Packaging - Kali Linux (push) Successful in 8m56s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m56s
CI / Packaging test (push) Successful in 0s
__find_circular_deps_recursive() builds the cycle path by inserting
each visited dependency at the front of the list on the way back up,
and __find_circular_deps() appends the project where the cycle was
detected at the end. The path therefore starts at the first child of
the DFS root instead of at the project that closes the cycle, and the
closing project appears twice: for a dependency cycle between projects
A and B, find_circular_deps() reports "B -> A -> A" instead of
"A -> B -> A".

Keep the DFS stack as an ordered list, and when a dependency is already
on the stack, return the part of the stack from that dependency to the
top, plus the dependency itself, which starts and ends at the same
project. Reverse the result before returning, because an edge
a -> b in the flipped graph means that b depends on a, so the cycle
is reported in the original dependency direction.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-22 16:11:34 +02:00
c95a3350ba App.__read_dep_graph(): Remove redundant loop
__read_dep_graph() iterates over the given sections (flavours), but
the loop body does not use the loop variable: it passes the entire
sections list to get_project_refs() on every iteration, so the same
lookup is repeated for each section, and the recursion into the
found dependencies is re-triggered (and skipped) for each of them.

Remove the loop and do the lookup once per project.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-22 16:11:34 +02:00
9a953d0017
lib.Uri: Fix stale cache in __new_with_path()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m4s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m6s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m13s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m53s
CI / Packaging test (push) Successful in 0s
__new_with_path() builds the new Uri by deep-copying self and then
replacing __string. A deep copy, however, also carries over any
cached_property values that were already computed on self (e.g. __p,
path, scheme, full), so once __string changes, they stay stale: for a
Uri on which any of those properties had been accessed before,
new_add_path() and new_replace_path() returned objects whose
to_string() showed the new string while path(), hostname(), full() and
friends still described the old one.

Build a fresh instance with object.__new__() and initialize its three
basic attributes instead of copying, so no computed cached state can
be inherited.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M and pi.dev
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-20 07:50:19 +02:00
c471388fba App: Remove ResultCache
All checks were successful
CI / Packaging - Kali Linux (push) Successful in 6m16s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m0s
CI / Packaging test (push) Successful in 0s
App.ResultCache is a horrible piece of software, now superseded by
functools.cache, with no measurable performance benefit as of now.
Remove it.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-18 13:02:04 +02:00
e3cff8104f lib.App: Find invoked path by walking argv
All checks were successful
CI / Packaging - Kali Linux (push) Successful in 3m36s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m47s
CI / Packaging test (push) Successful in 0s
The discovery re-parse re-parses the full command line at each level
against the subparsers registered so far. A level's subcommand parsers
are not registered until the re-parse descends into them, so the tokens
after the subcommand name are parsed against the current level's
options. An option meant for a deeper level can then collide with a
same-named option of a shallower level, or fail on a missing value.

Replace the re-parse with a single argv walk. The subcommand names at
each level are known once the commands are materialized, so the invoked
path is found by matching tokens against those names and skipping the
options (and the values they consume) that precede them. Walking the
tokens never parses the tail against a half-built parser, so the
collision cannot occur.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-18 01:14:40 +02:00
9f7e1b6cb2 lib.Cmd: Build the command tree lazily
App() construction builds the entire command tree: every
load_subcommands() call in a command's __init__() constructs its whole
subtree eagerly, so running a single leaf command pays to instantiate
every unrelated command object as well (jw-pkg builds about 50 command
objects for any invocation).

Defer the construction instead. load_subcommands() now records only the
module search path and name filter, and the subcommands are materialized
on first access to the children or child_classes property. The parser
reads children only down the invoked branch on the non-help path, so a
simple run instantiates just that path (jw-pkg builds 5-7 objects),
while the help and completion path expands every node and leaves
rendered help unchanged.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-18 01:14:40 +02:00
13004d8909
lib.App: Add _root_cmd()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m15s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m11s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m56s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m0s
CI / Packaging test (push) Successful in 0s
Expose __root_cmd (the command which may or may not be mounted at the
root of the subcommand hierarchy) as _root_cmd() to derived classes.
This supports jw-ev's App base class, which specializes it to get hold
of jw.ev.app.Cmd's specific properties.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-18 00:45:49 +02:00
6b4bcdfaf8
lib.App: Add a root command slot
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m23s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m28s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m58s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m16s
CI / Packaging test (push) Successful in 0s
The application's top-level behavior is defined by overriding
App._add_arguments() and App._run(). The lightweight run-and-options
unit, Cmd, can already be mounted at any node of the command tree, but
the root is reserved for the application itself. An application that
wants to host a plain command at the top level therefore has to
subclass App and carry its full lifecycle implementation.

Add a root parameter to App.__init__(). When it is given a command
class, App instantiates it and uses it as the top level: the command's
options are registered on the top-level parser, it becomes the parent
of the top-level subcommands, and App._run() delegates the run to it.
The command's children are wired as the top-level subcommands, so the
same Cmd can now occupy the root node. When root is not given, the
previous auto-discovery behavior is preserved unchanged.

Keep the top-level subcommand heading as plain "Available subcommands"
whether it is hosted by the application or by a root command, while
nested command levels continue to qualify the heading with the parent
name. Add a unit test that mounts a root command hosting a child and
checks option registration, dispatch, setup and teardown, and
resolution of the application through the parent chain.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-17 12:53:05 +02:00
24e3059d92
lib.App.add_cmd_to_parser -> .make_sub_parser()
Code beautification: add_cmd_to_parser() isn't very telling about its
return type and the fact that it creates an object, hence the name
change. Also, annotate its argument with a private argparse type to
avoid a cast. My concern that argparse will break the private type at
some point in the future is outweighed by the gained clode clarity in
this function.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-17 12:53:05 +02:00
ee332c9d70
lib.App: Fix --help with required top-level args
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m11s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m17s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m53s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 6m49s
CI / Packaging test (push) Successful in 0s
_build_parser() does an early parse_known_args() to configure logging
from the command line, but that call also enforces the top-level
required arguments. --help is registered only after the early parse so
the subcommands are present in the rendered help, so an app with a
required top-level positional, such as a root Cmd that takes a
config-file, exits with "required: config-file" on --help before the
final parse_args() in __run() can handle it.

Skip the early parse when help or shell completion is requested (the
add_all_parsers flag, already set for -h, --help, and argcomplete). The
subcommands and --help are still registered, and the final parse_args()
shows the help without enforcing the required arguments. The log-flag
configuration and the running-command debug line move inside the guard;
neither help nor completion logs, so they do not need them.

Assisted-by: pi <unsloth/Qwen3.8-27B-GGUF:Q4_K_M>
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-17 12:02:05 +02:00
6308fb2690
lib.Types: Accept bare string in LoadTypes()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m6s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m4s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m14s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m24s
CI / Packaging test (push) Successful in 0s
LoadTypes() declares mod_names as Iterable[str], so passing a single
module name as a bare string is not caught at call time and the string
is iterated character by character at load time, producing a
ModuleNotFoundError for the first character instead of a clear error.

Normalize a bare string to a one-element list in __init__() and widen
the annotation accordingly, so that both forms work.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 21:08:52 +02:00
15b2735afa
lib.distros.redhat.Distro: Add missing file
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m3s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m54s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m8s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m11s
CI / Packaging test (push) Successful in 0s
Add the (untested) module lib.distros.redhat.Distro. It had been
lingering in the source tree, but I've apparently forgotten to add it
to Git. It has never seen any real use because CI still doesn't run
a RedHat distro, so it is to be regarded as a stub. Which is better
than nothing.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 20:08:32 +02:00
ac35da6d9c
lib.AsyncRunner: Fix asyncio.Event() for Python 3.12+
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m33s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m15s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m2s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m53s
CI / Packaging test (push) Successful in 0s
AsyncRunner is currently unused. This bug was detected and fixed by
AI.

asyncio.Event() raises RuntimeError on Python 3.12+ when created
outside a running event loop. It is created in the sync portion of
loop_in_thread(), before the threaded loop is up.

The fix is to move the Event creation inside the async main()
coroutine and pass it back via a second future. It replaces the
fragile as_completed loop with sequential result() calls, so failures
are immediately visible rather than causing a silent thread hang.

Assisted-by: unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_M with pi.dev v0.84.1
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 19:51:36 +02:00
75b6603a3f
lib.Cmd: Add single Cmd to add_subcommands()
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m32s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m30s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m18s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m59s
CI / Packaging test (push) Successful in 0s
add_subcommands() advertises Cmd and list[Cmd] in its signature, but
a single Cmd instance raises NotImplementedError, and since the list
branch handles every element through the same method, a list of Cmd
instances is broken as well. The only working forms are Types and
lists of Types.

Handle a single Cmd instance by reparenting it to the caller and
appending it to the children, tracking its class like the class-based
path does. Instances whose name is already taken by a child are
rejected, mirroring the duplicate-class handling, because argparse
cannot register two subparsers under the same name.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
d9cc2f3012
lib.App: Pass None default to os.getenv()
The os.getenv() calls in __init__() that read the log and backtrace
defaults mostly pass None as the explicit default value, but the one
for the show-backtrace environment variable relies on the implicit
default.

Pass None explicitly there as well, so that all the calls read the
same way.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
32d46df18d
lib.App: Log reason for skipped completion
The shell completion setup in __run() catches every exception and
silently ignores it. If argcomplete is missing or its initialization
fails, the completion is simply not available and there is no trace
of why, even when logging is turned up to debug level.

Log the reason at debug level: one message when the argcomplete
import fails and one with the exception for any other failure.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
d8ed0c95d3
lib.App: Warn on invalid exit status
__run() only accepts a return value from _run() as the process exit
status if it is an int between 0 and 255, and silently drops any other
value. A command that returns, for instance, 300 therefore exits with
status 0, which presents a failure as a success to the caller without
any trace of the mistake.

Log an error when the returned exit status is out of range so that the
programming error is visible, while still exiting with 0 instead of
passing an invalid status to the shell.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
3ac649cdf1
lib.App: Tidy up subcommand registration
The subcommand registration in _build_parser() defines a SubCommand
helper class inside the add_cmds_to_parser() closure, so a fresh class
object is created on every call. It also stores command names and
aliases in a dictionary without checking for duplicates, so a colliding
name or alias is silently overwritten, and it relies on every subparser
level sharing the dest = 'command' attribute to descend one level per
re-parse, an invariant that is not documented anywhere.

Hoist the helper to a module-level _SubCommand NamedTuple, log a
warning when a subcommand name or alias collides with an earlier one at
the same level, and document the dest = 'command' invariant next to the
re-parse.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
0be539a40a
lib.App: Use parser in _add_arguments()
_add_arguments() adds the global options to self.__parser instead of
to the parser it receives. The two are the same object, because the
only caller passes self.__parser, so the change is not observable.

Use the parser parameter instead, so that the method honors its
argument the way Cmd.add_arguments() does, and so that the global
options can be shared with other parsers, e.g. the subcommand
parsers, without rewriting this method.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
f706477f18
lib.App: Use args parameter in _run()
_run() receives the parsed arguments as its args parameter, but then
checks the private __args attribute for the func attribute and resolves
the command function through the args property. Both refer to the same
object today, so the mixing is harmless, but it obscures the data flow
and would silently diverge if a caller ever passed a namespace other
than the stored one.

Use the args parameter consistently in _run().

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:47 +02:00
3fce4b27f8
lib.App: Rebuild parser from run() argv
__init__() builds the parser and the lazy subcommand registration
inside it decides which subcommands to register by re-parsing
sys.argv. run() then parses a different argv, so if the caller passes
an argv that is deeper than the one in sys.argv, the required
subparsers have not been registered and the invocation fails with an
"unrecognized arguments" error. run_sub_commands() passes argv to
run(), so the mismatch is reachable from the public API.

Move the parser construction from __init__() into _build_parser() and
call it from run() when an argv is given, so that registration and
parsing are driven by the same command line. The top-level command
instances are created once in __init__() and reused when the parser
is rebuilt.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:46 +02:00
845601ff10
lib.App: Restore previous event loop in run()
When run() creates an event loop, it installs it with
set_event_loop() but never restores the thread's previous loop, so
after run() returns, the thread is left with the now-closed loop
created by run(). Any code that calls get_event_loop() afterwards
gets a closed loop, and on Python 3.13+ a thread that had no loop at
all starts emitting or raising deprecation errors that run() caused.

Capture the thread's current loop with _get_current_event_loop()
before installing a new one, and restore it in the finally block. If
there was no previous loop, unset the loop with set_event_loop(None)
so that the thread is left without a loop instead of with the closed
one.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:46 +02:00
157fa86fb7
lib.App: Release async runner in close()
close() closes the application's own event loop, but the AsyncRunner
is only released in the finally block of run(). An application that
creates a runner through call_async() and then calls close(), for
instance through the async context manager, therefore leaks the
runner, and close() does not fulfill its contract of releasing all
resources.

Move the AsyncRunner cleanup from the finally block of run() into
close() and reset the own-loop flag when the loop is closed, so that
close() releases everything and run() only has to call it.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:46 +02:00
679e66898e
lib.App: Implement __aenter__() and __aexit__()
__aenter__() and __aexit__() are empty stubs. Using the application
as an async context manager therefore binds None in the as clause,
and releases nothing on exit: an AsyncRunner created through
call_async() keeps running in its thread, and since that thread is
not a daemon, the process does not exit after the block.

Return self from __aenter__(), and call close() from __aexit__(), so
that the context manager binds the application and releases all
resources on exit, whether the block exits normally or with an
exception.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:46 +02:00
8c47726a8d
lib.App: Fix crash on invalid log options
The --log-level and --log-flags options are added without a type
converter, so argparse never validates their values. _build_parser()
then hands the raw string to set_log_level() and set_log_flags() during
its first parse, and an unparseable value such as "INVALID" crashes
__init__() with a raw ValueError traceback instead of a usage error.

Pass type = parse_log_level() and type = parse_log_flags() when adding
the options, so that argparse reports invalid values with the standard
usage error and exit status 2. argparse only applies the converter to
command-line strings, so the int and LogFlag defaults are unaffected.

Assisted-by: unsloth/Qwen3.8-27B-GGUF:Q4_K_M with pi.dev v0.84.2
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-08-15 15:58:46 +02:00