9 commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 595995e084 | |||
| d7f9fc7260 | |||
| 060ff5159b | |||
| 4274a71c62 | |||
| 9c06103a4a | |||
| f175f9d5c9 | |||
| 95fa2f0d06 | |||
| aefe983920 | |||
| 0b83c863a2 |
Renamed from src/python/jw/pkg/build/cmds/CmdGetAuthInfo.py (Browse further)
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 595995e084 |
jw.pkg.cmds: Replace split('\n') by splitlines()
splitlines() removes empty lines, so use it and save some lines of code. Signed-off-by: Jan Lindemann <jan@janware.com> |
|||
| d7f9fc7260 |
CmdAuthInfo: Fix no output
jw-pkg.py projects get-auth-info doesn't print anything, fix that. Signed-off-by: Jan Lindemann <jan@janware.com> |
|||
| 060ff5159b |
jw.pkg.cmds.projects.CmdGetAuthInfo: Fix run_cmd()
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> |
|||
| 4274a71c62 |
lib.util.run_cmd(): Rewrite it to be async
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> |
|||
| 9c06103a4a |
cmds.project.*: Make _run() async
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> |
|||
| f175f9d5c9 |
lib.Cmd: Add argument "parent" to __init__()
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> |
|||
| 95fa2f0d06 |
jw.pkg.App: Remove .debug() and friends
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> |
|||
| aefe983920 |
jw.pkg.App: Support --topdir-format
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> |
|||
| 0b83c863a2 |
jw.build.cmds: Move build.cmds -> cmds.projects
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> |