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.
https://my-company.com/src/theowner/jw-pkg.git
would have a --remote-owner-base of
https://my-company.com/src/theowner
Also, change what --remote-base returns to
https://my-company.com/src
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Replace --source-profile by --env-reinit and --env-keep to allow more
fine-grained control over environment manipulation.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Trying to find the directory of a project should log a warning. It
throws an exception instead. Fix that.
Signed-off-by: Jan Lindemann <jan@janware.com>
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
Fix API breakage in the command modules.
Signed-off-by: Jan Lindemann <jan@janware.com>
--quote puts double quotation marks around the listed dependencies,
protecting version requirements (>= 1.0) and parenthesis "perl(GD)"
from the shell.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
run_cmd() is synchronous. Now that all commands are asynchronous, we
can await it, so rewrite it to be asynchronous, too.
Other changes:
- Make it return stderr as well in case its needed
- Drop into a pseuto-tty if
- cmd_input == "mode:interactive" or
- cmd_input == "mode:auto" and stdin is a TTY
- Add argument env, defaulting to None. If it's a dict, it will be
the environment the command is run in
This entails making all functions using run_cmd() async, too,
including run_curl(), get_username() and get_password().
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Add the Enum "Scope" to denote the scope argument of
jw.pkg.App.get_modules_from_project_txt(), because it explains itself
better than an integer.
Signed-off-by: Jan Lindemann <jan@janware.com>
App.res_cache should be private. It's needed here to cache the
results of a function which is private to CmdBuild anyway, so solve
that with lru_cache, to allow App to do it's private thing with
caching.
Signed-off-by: Jan Lindemann <jan@janware.com>
Replace the jw.pkg.App.debug(), .warn() and .err() methods by the
global log() function. There's no obvious benefit in having App know
what's logged.
Signed-off-by: Jan Lindemann <jan@janware.com>
Add support for --topdir-format. The option supports several
different values, affecting the console output of App wherever it
knows that the output contains a reference to the projects' toplevel
directory.
- "unaltered" will have it print the toplevel directory in the same
format as passed to the commandline
- "absolute" will try to resolve it to an absolute path before
printing
- make:XXX will return the make-varible $(XXX) instead
To implement this, the proj_dir() member function is turned into the
private member function __proj_dir(), and a new member function
find_dir() is supplied, with two additional parameters:
search_subdirs and search_absdirs, which will try to find an existing
directory relative to the toplevel directory of the given module, or
in the search_absdirs list, respectively.
Command modules in cmds.projects have been updated to use the new
function.
Signed-off-by: Jan Lindemann <jan@janware.com>
Reorganize the Python module structure. Placing the command classes
under jw.cmds.projects instead of jw.build.cmds will allow to add a
nested command structure, with the current commands, being mostly
related to building software, found below a "projects" toplevel
command.
Other conceivable commands could be "package" for packaging, or
"distro" for commands wrapping the distribution's package manager.
Signed-off-by: Jan Lindemann <jan@janware.com>
