TL;DR: kill https://github.com/wpilibsuite/bzlmodRio-libssh, update
versions, and make things easier for a script to update.
The main motivation behind this was that libssh was out of date with the
gradle version. Using these "external" dependencies can cause agita as
we churn through toolchain updates. Unlike the toolchains and opencv,
which can be used by external users (i.e. a all bazel robot, if a vendor
wanted to use bazel) a C++ wrapper around libssh maven deps almost
certainly wouldn't be pulled in, much like ceres and mrclib.
As a result of vendor'ing libssh, and knowing some potential pitfalls
and annoyances, this PR does the following:
- Vendor libssh, akin to how mrclib is pulled in
- Moves the vendor'd ceres to `shared/bazel/thirdparty`, and refactors
it to better match mrclib. To me it doesn't necessarily belong in its
`thirdparty` location because it is bazel only.
- Due to the refactoring, libssh and ceres can now be pulled into
`MODULE.bazel` instead of the `WORKSPACE.bzlmod` helper. This is good
prep for a potential upgrade to killing `--enable_workspace` / bazel 9
- Write a python script that can deal with the integrity / sha256 of the
http_archives. I suggested this be added to davo's mrclib PR, but this
one is a little bit more robust and will actually edit the files in
place. This makes upgrading versions substantially easier.
- Upgrade libssh version to what gradle is using, and mrclib to the
version in #8858. These changes have been tested against that PR.
Using MrcLib on the robot is going to be the plan for the future, to
make things easier.
MrcLib is how sim is supported going forward. The desktop version of
mrclib can act as a robot server.
This is set up where the mrclib interface is in shared code. On robot,
that is the only backend used. On desktop, a default sim backend is
used. However, the sim plugin can switch that to the real robot backend,
so the robot code will exactly look like a real robot.
This pulls in the `mrclib` maven repository as shared libraries, as a
prereq for #8858.
Alternative to #8869, which avoids the unnecessary lockfile entry. This
should be a one-to-one replacement for that PR.
Closes#8869
---------
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>