CmdGetAuthInfo calls run_cmd() with a list instead of a *-expanded list of arguments. Fix this to match the current run_cmd() prototype.
And think again if the current prototype conforms to the priciple of least surprise: Most exec- / run- / whatever- functions do expect ether a string to be run by the shell, or an argv list.
Prepending --login to the argument list of BackendCmd.sudo() fails if run as root, because BackendCmd.sudo() detects that and leaves the /usr/bin/sudo out from the exec call. Fix that by adding an opts: list[str] parameter to sudo, defaulting to an empty list, with options that should be passed to /usr/bin/sudo.
Define run(), which calls _run() in the abstract base class Cmd, not in lib.Cmd. Otherwise lib.Cmd is not abstract, which will predictably confuse including code outside of jw-pkg.
If VERSION_FILE is not found, trying to include makefile snippets triggers the attempt to regenerate it. This happened for installed Makefiles of jw-docker-images: It defines TOPDIR to /opt/jw-docker-images, projects.mk looks there, but the version file is installed under /usr/share/doc/packages/jw-docker-images/VERSION.
Allow VERSION_FILE to be overridden including code to keep that from happening.
make complains for plugins that soandso.dll has not been remade. The problem is that it tries to remake all targets of a multi-target. Split that up into two rules.
Calling make git-pull-xxx from a projects directory stops iterating projects if one has a dirty workspace. Calling --autostash fixes that.
With this in place, a failed rebase leaves the local changes behind stashed. So, after manually fixing the rebase, the stash needs to be manually reapplied. The commands that led up to the failure are logged right before, so I have hope that this is learnable, and not too much of a footgun.
.cache-projects.mk is not installed / packaged, which makes builds against an installed jw-pkg considerably slower. Change that, at the risk of making the installed jw-pkg-devel less versatile. This commit installs a cache file cache-projects.mk, renamed from .cache-projects.mk, because there's no justification for hiding an installed makefile. At least I can't think of one.
Before merging the remote branch, do a rebase. This may fail and prompt conflict resolution, but that seems the canonical outcome for the common use case "interactive make git pull-xxx" with master out-of-sync.
There's pkg-manager-refresh already, so by adding pkg-manager-dup the distribution can be upgraded by distribution agnostic targets only through the Makefile. This might come in handy for CI, so add it.
Major - but not yet sufficient - code beautification starting from jw.pkg.App.
- Make more methods private
- Rename methods to be more self-explanatory
- Same for method arguments, notably clean up some inconsistent
uses of "module" vs "project"
- Add more type hints
--quote puts double quotation marks around the listed dependencies, protecting version requirements (>= 1.0) and parenthesis "perl(GD)" from the shell.
A "username" in jw-pkg terms, as in $(CLONE_FROM_USER), is not sufficient to identify a remote API URL on a Forgejo server, it can denote both an organization and a user, so try organizations first, then users, and stop on the first occasion found.
Retire pkg-manager.sh and replace it by the cleaner "jw-pkg.sh distro" command, essentially providing the same functionality and nearly the same command-line interface.
400 LOC more. That's what the move from a shell script to the more maintainable Python versions costs. Still a good idea, and the enhanced extensibility might pay off in terms of LOC with other shell scripts in the future.
Add a hand-coded __init__.py into jw.pkg.cmds.distro. Auto-generation works fine, but has to run before it can work. For a freshly downloaded toplevel Makefile / project-dirs-minimal.mk, the targets pkg-install-xxx-deps requires a working package manager without jw-pkg built.
Cmd._run(), as conceived for working with lib.App, is meant to be an async method. To be conservative about changes, jw-pkg's legacy way of handling _run() was kept when deriving from libApp, and async was not propagated down to the _run() implementations. This commit rectifies that before adding additional subcommands.
During __init__(), commands have no idea of their parent. This is not a problem as of now, but is easy to fix, and it's architecturally desirable to be prepared just in case, so add the parent argument to the ctor before more commands are added.
As per info make, it turns out that ifndef SOME_VAR is true for SOME_VAR defined to an empty value. This is unusable for caching, so replace it with ifeq ($(origin SOME_VAR),undefined).
