Lots of sub- and sub-subcommands are derived from the base class of the invoking command, notably below cmds.projects. That provides some properties shared across the ancestor hierarchy of a command, but is semantically unsound. Introduce jw.pkg.BaseCmd class as a place to provide basic helpers shared across all commands used in a jw.pkg.App's context. Also add cmds.projects.Cmd to be used by other commands in cmds.projects in later commits.
Exceptions raised by the build command are handled and changed, messing up the stack trace. Re-raise the original exception from the exception handler to fix that.
Enclose ExecContext._run() in an open() / close() - pair. This is convenient for the caller in that it doesn't need to take care of opening and closing for one call only, and inconvenient in that it forces the caller to conciously add an open() / close() - pair around multiple run() calls where it wants the context to stay open in between. Or use the ExecContext as a context manager.
There are a couple of assert statements in the codebase which can make jw-pkg fail without any detail whatsoever if --backtrace is not specified, fix that.
Commit a19679fec reverted the first attempt to make AsyncSSH reuse one connection during an instance lifetime. That failed because a lot of distribution-specific properties were filled in a new event loop thread started by AsyncRunner, and AsyncSSH didn't like that.
This commit is the first part of the solution: Move those properties from the App class to the Distro class, and load the Distro class in an async loader. As soon as it's instantiated, it can provide all its properties without cluttering the code with async keywords.
The name of the env parameter to ExecContext.run() and .sudo() is not descriptive enough for which environment is supposed to be modified and how, so rename and split it up as follows:
- .run(): env -> mod_env
- .sudo(): env -> mod_env_sudo and mod_env_cmd
The parameters have the following meaning:
- "mod_env*" means that the environment is modified, not replaced
- "mod_env" and "mod_env_cmd" modify the environment "cmd" runs in
- "mod_env_sudo" modifies the environment sudo runs in
Fix the fallout of the API change all over jw-pkg.
For now, move the definiions of Result, Input and InputMode from ExecContext into lib.base. Having to import them from the ExecContect module is too heavy-handed for those simple types.
The Input instance passed as cmd_input to ExecContext.run() and .sudo() currently may be of type str. Allow to pass bytes, too.
At the same time, disallow None to be passed as cmd_input. Force the caller to be more explicit how it wants input to be handled, notably with respect to interactivity.
Along the way fix a bug: Content in cmd_input should result in CallContext.interactive == False but doesn't. Fix that.
CmdCanonicalizeRemotes / canonicalize-remotes and the respective target in topdir.mk remove the /srv/git portion from all remotes' URLs pointing to git.janware.com.
Make variable names a little more readable and searchable within the long pkg_relations_list() method by making their names longer and truer to what they actually mean.
CmdPrereq was mostly redundant to PkgRequired all along. CmdPrereq has grown more versatile, and CmdPrereq is not used throughout jw-pkg anylonger by now. Remove it.
print() should be used to output information requested by a certain command, but not for logging the process to achieve it. log() should be used for the latter. The current code has the distinction not down clearly, fix that.
print() should be used to output information requested by a certain command, but not for logging the process to achieve it. log() should be used for the latter. The current code has the distinction not down clearly, fix that.
Since commit 02697af5, ExecContext.run() returns bytes for stdout and stderr and fixes that in calling code. The thing it did not fix was the code calling run_cmd(), which also made return bytes. This commit catches up on that.
ExecContext's .sudo() omits many of run()'s parameters, and this commit adds them. To avoid redundancy around repeating and massaging the long parameter list of both functions and their return values, it also adds some deeper changes:
- Make run(), _run(), sudo() and _sudo() always return instances of
Result. Before it was allowed to return a triplet of stdout,
stderr, and exit status.
- Have ExecContext stay out of the business of decoding the result
entirely. Result provides a convenience method .decode()
operating on stdout and stderr and leaves the decision to the
caller.
This entails miniscule adaptations in calling code, namely in
App.os_release, util.get_profile_env() and CmdListRepos._run().
- Wrap the _run() and _sudo() callbacks in a context manager object
of type CallContext to avoid code duplication.
- Consistently name the first argument to run(), _run(), sudo() and
_sudo() "cmd", not "args". The latter suggests that the caller is
omitting the executable, which is not the case.
In a push to eventually merge the classes, somewhat align the command-line API of CmdRequiredOsPkg to the one of BaseCmdPkgRelations by using dependency flavours as mandatory, first argument.
To support the pkg-install-testbuild-deps target, a selector is needed listing all prerequisites to be installed except the project under test. --hide-self should be useful for that.
Add a function pkg_relations_list(), doing pretty much the same as pkg_relations(), but taking individual arguments instead of an argparse.Namespace args argument, in order to provide the functionality to derived classes.
Add support for --syntax to BaseCmdPkgRelations.pkg_relations(), and default to 'semver', i.e. the current state of affairs. If that's changed to 'debian', relations declared in project.conf as
should include all packages required by flavour devel, because during the release process, -devel and -run packages are both installed, and installing the -devel package is only possible if its dependencies are installed.
Most run_xxx() return stdout and stderr. There's no way, really, for the caller to get hold of the exit code of the spawned executable. It can pass throw=true, catch, and assume a non-zero exit status. But that's not semantically clean, since the spawned function can well be a test function which is expected to return a non-zero status code, and the caller might be interested in what code that was, exactly.
The clearest way to solve this is to return the exit code as well. This commit does that.
Support --remote-owner-base in the command CmdGetAuthInfo. Make it return what currently --remote-base returned: A URL including the user / organization specific prefix of the Git remote's URL that jw-pkg was pulled from.
Rename the --from-user option to --from-owner. Forgejo supports users and organizations under the more general term "owner", so that's the better term.
list-repos tries /users/ and /orgs/ to find a working repo URL in a Forgejo instance, logs a failure and doesn't log anything if it finds one that works. In the context, that can be mildly confusing, beautify the output somewhat.
base-url is not used as a prefix in its entirety, but massaged in a janware-specific way. Still is, but at least this commit is a step towards being more generic.
This is a code maintenance commit: some run_xxx() helper functions take a string, some a list, and some just digest all arguments and pass them on as a list to exec() to be executed. That's highly inconsistent. This commit changes that to list-only.
Except for the run_cmd() method of SSHClient, which is still run as a shell method, because, erm, it's a shell. Might be changed in the future for consistency reasons.
