get-os.sh returned "suse" for SuSE-like distros, and that seems more appropriate since SLES is not OpenSUSE but should share and ID with other SuSE variants.
App.distro_id used to return "opensuse-tumbleweed", analogous to what's in ID@/etc/os-release, but now returns "opensuse", and the "tumbleweed" goes into "codename". That matches more what Debian-like distributions do, but it confuses _backend_path. Adapt it to map the new distro_id correctly.
PKG_FORMAT is now more straightforward to get with from the revised jw-pkg.py distro info --format '%{cascade}', so do that, and do it in the context where all the other variables are set from the output of that command.
To remove redundancy, get-os.sh needs to be retired in favor of pkg.py distro info. It's needed in platform.mk, but the only definiton of JW_PKG_PY is in projects.mk, so move it, along with the variables essential for the command:
include $(JWBDIR)/make/py-version.mk (defining PYTHON) JW_PKG_PY DEVELOPMENT VERSION_FILE
CmdInfo provides what "projects os-cascade" provided as "distro info --format '%{cascade}'" plus additional macros: %{id}, %{name}, %{codename} and ${gnu-triplet}.
pkg.run is not evaluated on Debian, fix that. For now it's hacked into pkg.sh, which is bound to be replaced by Python. The limited hassle is still worth the detour.
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.
Deduce module search path for the calling module's subcommands directly from the module path of the calling module. That's more generic than the previous detection algorithm, because it recursively works for subcommands of subcommands as well.
Currently git-get-% pulls into the master branch. Change that to pull into the branch currently checked out in the workspace, because that's the more likely use case if you want a quick update from somewhere.
PGIT_SH_PROJECTS currently only sets the projects to operate on for the get command. Extend this to all commands. And replace the environment variable by a command-line option, likely after this script has been ported to Python.
"clone" in the Git sense means to copy a remote project over from scratch. pgit.sh clone has come from that, but has since evolved into something different, a mixture of clone, pull and fetch, so find a different name. "get" seems generic enough and doesn't clash with a Git meaning. Adapt variable names accordingly across the project.
