Commit graph

18 commits

Author SHA1 Message Date
77c746571a
scripts: Fix shellcheck errors
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m23s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m30s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m2s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m6s
CI / Packaging test (push) Successful in 0s

Fix shellcheck SC2068 (unquoted array expansions), SC2145 (mixed string/array arguments), SC2328 (redirection in command substitution), SC2173 (untrapable signals), and SC2148 (missing shebang) errors across 14 script files.

Also configure scripts/Makefile with --severity=error so that only errors (not warnings or notes) cause check failures. To be tightened by follow-up commits.

Assisted-by: unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_NL and pi.dev
Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-29 17:52:24 +02:00
45f8e8cc89
test + python-tools.sh: Fix toplevel "make all" fallout
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m14s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 4m20s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m45s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m52s
CI / Packaging test (push) Successful in 0s

After a pipeline change, CI now runs "make all" in a repo's root, which uncovers two problems:

1. The help integration test only succeeded as long CI didn't run "make all" before "make test". That way, the checked out repository lacked the generated __init__.py files needed for some modular subcommands to be fully loaded, and hence, the test should have failed. The entire machinery only worked because the subcommands in question are not not essential to building jw-pkg itself: "secrets" and "posix". So, this commit adapts the help integration test to the new reality.

2. Regarding python-tools.sh: Commit 55060486 satisfies yapf in some places of the source code, but in others not anylonger. So patch python-tools.sh's newline handling again.

While not thematically similar, both fixes get baked into one commit to satisfy the requirement that every single commit needs to pass "make clean all check test" individually.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-25 18:28:36 +02:00
5506048614
python-tools.sh: Fix missing newline after imports
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 4m42s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 5m11s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 4m12s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 4m15s
CI / Packaging test (push) Successful in 0s

Commit 4e347683 removed a tralining newline after imports. Yapf doesn't like that, so revert that change.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-25 16:44:35 +02:00
4e347683ef
python-tools.sh: Fix __all__ format violation
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 3m9s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m20s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m9s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m20s
CI / Packaging test (push) Successful in 0s

Make python-tools.sh generate empty __all__ as [] on one line instead of multi-line format, and remove trailing blank line.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-25 09:50:15 +02:00
d42040cb7b
py-mod.mk: Support PY_INIT_SUBMODULES
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 3m3s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m12s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m2s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m21s
CI / Packaging test (push) Successful in 0s

Add support for PY_INIT_SUBMODULES to py-mod.mk. If it is defined in a Makefile including py-mod.mk, the listed submodules will be added to __init__.py and thus included in the list of things that can be imported from a module.

This commit also adds support for --submodules to python-tools.sh for that to happen.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-17 19:32:40 +02:00
335b9d601a
python-tools.sh create-init: Code beautification

Make the code in cmd_create_init() and command-line parsing a little less ugly.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-12 09:58:56 +02:00
9039dc7e40
python-tools.sh, py-mod.mk: Use --symbol-filter
All checks were successful
CI / Packaging - Kali Linux (pull_request) Successful in 3m8s
CI / Packaging - OpenSUSE Tumbleweed (pull_request) Successful in 3m22s
CI / Packaging test (pull_request) Successful in 0s
CI / Packaging - Kali Linux (push) Successful in 3m9s
CI / Packaging - OpenSUSE Tumbleweed (push) Successful in 3m14s
CI / Packaging test (push) Successful in 0s

Letting python-tools.sh rewrite symbols is more robust than rewriting an entire __init__.py with PY_INIT_FILTER in the including Makefile. The latter can break in non-obvious ways if python-tools.sh changes __init__.py's format.

Make python-tools.sh support --symbol-filter to remedy that. The option takes an sed script which should expect a string of two non-whitespace tokens: The module from which the symbol is imported, and the name of the symbol in that module. It's output will then be used as the symbol to be exported from __init__.py.

Also, support the PY_SYMBOL_FILTER variable in py-mod.mk. If it's defined, it is used for --symbol-filter.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-12 07:33:07 +02:00
f27ffae5cd
python-tools.sh: Create empty line after import

The generated code doesn't pass "make check": It would like to see a newline after the import statement. Add that.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-06-01 20:14:45 +02:00
fc6f2fbb65
python-tools.sh: Fix __init__.py linter complaints

The __init__.py files as gnerated by python-tools.sh contain multiple issues, fix them:

- Make the machinery fail if the same type name is imported from different modules
- Support relative imports from .Module import Module instead of having to use the entire module path as import source

- Import types explicitly re-exported with "as":

from .Module import Module as Module
Otherwise ruff will regard the type as "imported but not used"
- Add "# ruff: noqa: E501" near the top. The import lines can get long and are beyond manual control (except for renaming the modules themselves, that is). This can cause ruff to fail, so get it to accept long lines in __init__.py. The style violation doesn't make much of a difference in generated code, anyway, because nobody reads that. Plus what's happening in the code isn't rocket science, so good style wouldn't help much with understanding, either.

This promptly digs up two symbol name conflicts lib.pm.dpkg and lib.pm.rpm. Fix them along with this commit to keep it from breaking the build.

Signed-off-by: Jan Lindemann <jan@janware.com>
2026-05-31 17:51:51 +02:00
d7d4ffa640 py-run.mk, python-tools.sh: Re-add files necessary for jw-client-devops-web

jw-client-devops-web needs py-run.mk and python-tools.sh, add them.

Signed-off-by: Jan Lindemann <jan@janware.com>
2025-11-14 17:15:24 +01:00
bc883deed4 Everywhere: Remove everything non-essential for "make clean all"

This commit removes everything not strictly necessary for running "make clean all" inside jw-build.

packaging jw-devtest. This cuts the repo down from 24077 to 4725 lines of code.

The idea is to

1) Further remove bloat from the remaining bits

2) Re-add what's necessary to build and package other essential repos.

The decision should be based on whether or not jw-build can also be useful in a non-janware context.

Signed-off-by: Jan Lindemann <jan@janware.com>
2025-11-14 15:02:56 +01:00
b77d92794e python-tools.sh: Fix __path__ type check in __init__.py

Don't check __path__ as Interable[str] anylonger, this somehow broke (Don't remember how). Use type: ignore instead.

Signed-off-by: Jan Lindemann <jan@janware.com>
2024-04-30 09:00:45 +00:00
a404be15b9 make, scripts: Add support for static Python typechecking

This commit adds support for static typechecking with mypy.

Notable additions:

- A new target "check" which does the type checking

- Py-mods.mk, meant to be included from a directory containing python modules in subdirectories, but not being a python module itself. It makes the all target depend on check only if PY_RUN_CHECK_AFTER_BUILD is defined and true. That's because pypy is under heavy development, and the Ubuntu 18.04 version is too old to work for lots of the code.
Signed-off-by: Jan Lindemann <jan@janware.com>
2020-04-10 12:13:12 +00:00
7fb117a4c4 python-tools.sh: Make __init__py recognize multiple package modules

import my.mod.thing, my.mod.thang wouldn't work, if the modules where not in the same directory hierarchy, e.g. in $(HOME)/blah/my/mod/thing.py and $(HOME)/blub/my/mod/thang.py, not even with PYTHONPATH=$(HOME)/blah:$(HOME)/blub.

This commit fixes that.

See https://stackoverflow.com/questions/1675734

Signed-off-by: Jan Lindemann <jan@janware.com>
2020-04-05 12:51:11 +00:00
a935715036 python-tools.sh: Code beautification

This commit beautifies module import path deduction a little. It also adds (disabled) code for importing submodules, which may or may not be enabled by a command-line option in the future.

Signed-off-by: Jan Lindemann <jan@janware.com>
2019-10-28 12:20:52 +00:00
ba314df490 python-tools.mk: Fix __init__.py generation
Signed-off-by: Jan Lindemann <jan@janware.com>
2017-07-25 15:05:21 +00:00
55f9b50562 py-defs.mk, py-mod.mk, python-tools.sh: Improve python module handling

- Fix superflous dots in module names - Generate PYTHONPATH in projects.py - Add support for __init__.py.tmpl

Signed-off-by: Jan Lindemann <jan@janware.com>
2017-07-24 10:59:08 +00:00
9505e9ab40 python-tools.sh: Add python-tools.sh
Signed-off-by: Jan Lindemann <jan@janware.com>
2017-07-22 14:33:36 +00:00