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.
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.
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.
$(TOPDIR)/scripts contains a symbolic link jw -> ../src/python/jw, to allow jw-python.py access to the in-repo module jw.pkg. Should be fine now even on Windows, OTOH, it's also solvable via __init__.py, so do that.
To support minimal environments, notably minimal Docker containers which don't have /usr/bin/sudo by the time pkg-manager.sh is invoked (possibly to install sudo), support running all commands without invoking sudo first. Of course this only works if invoked as root.
Note that this is still somewhat hacky, command-line parsing needs to be cleaned up.
"git fetch $remote $fromref:$toref" fails if the $fromref is behind $toref.
Unrolling the syntax into "git fetch" followed by "git merge --ff-only $remote/$fromref $toref" is accepted, though, and saves some otherwise necessary case distinction code around it.
jw-build doesn't stop at building software, packaging it afterwards is also a core feature, so this commit gives the package a better name.
The commit replaces strings s/jw-build/jw-pkg/ in text files and file names. Fallout to the functionality is fixed, variable names are left as they are, though. To be adjusted by later commits.
--login is not understood by pgit.sh push. Solve that by allowing all commands a --login option. This addresses our use case, but isn't ideal of course. Will be finally fixed by moving pgit.sh's functionality into Python code.
pgit.sh clone --login <username> fails to insert said username into a remotes url while adding it: Of ssh://<username>@git.janware.com/srv/git, only ssh://@git.janware.com/srv/git makes it into the config. Fix that.
In the attempt to move away from communicating options via environment variables from one part of jw-build software to another, replace PGIT_CLONE_FROM_USER with the clearer --refspec option. Which is also more versatile.
Don't unconditionally add proactiveAuth=basic to Git's config during clone, but only if cloning happens after authentication.
This saves unauthenticated users funny password prompts. On the other hand, this makes a server setting persistent which could be changed on the server.
URL =~ /api/ (or so) => 401, followed by Basic Auth URL !=~ /api/ (or so) => Redirect or free access, depending on resource
Currently all resources, including API, are accessible by either basic auth or a Cookie, but basic auth needs to be present in the first request, which throws off some clients (notably Git without proactiveAuth=basic).
Replace git-srv-admin.sh list-personal-projects by the more universal "jw-projects.py list-repos" for enumerating repo names. This is a step towards supporting Git servers other than janware.com.
Add support for --create-user-repos to pgit.sh. It controls whether or not personal remote repositories on janware.com are created when cloning from another user.
jw-pkg is related to, but strictly speaking not indispensible for building and packaging software. So, in the attempt have a minimal jw-build, move jw-pkg to jw-base, and fix all packages that use it.
There's a certain logic that jw-pkg is part of jw-build, because it comes in handy to compile config file templates in a post-install stage. On the other hand, jw-base looks like a better place for that.
Re-adding for now, to not break too many packages.
Implement the functionality of create-pkg-config.sh in a Python module CmdCreatePkgConfig.py. This allows to remove create-pkg-config.sh and jw-build-functions.sh.
Note that the translation was done pretty literally to play it safe. More code can and should be removed by taking advantage of the fact that jw-projects.py knows more about the project than the shell scripts.
Re-add everthing needed for building and packaging ytools. This is a big commit, 2002 lines of code. It mostly consists of C/C++ machinery, plus some documentation-related stuff.
