Add support for installing non-pure-Python packages from PyPI

[KellenWatt]

Presently, the installer functionally only supports none_any wheels from PyPI, since linux_roborio isn't a valid platform, according to PyPI. This adds support for extension modules that support the linux_armv7l platform. These modules should be able function on the RoboRIO, so long as they aren't attempting to access board-specific features. This case seems like it should be vanishingly rare at the FRC level though.

It may also be reasonable to add support for manylinux_armv7l targets, though since the RoboRIO doesn't claim to support those, I don't know if it would work.

Motivation

I made an embeddable automation language ostensibly designed for use with Command-based Autonomous mode, written in Rust for efficiency. When compiled to target the RoboRIO, it works as expected, including relevant Python bindings. With this change to the installer, specifically syncing, it installs onto and controls the robot as expected, with no noticeable issues. Installing this manually is possible, but I'd rather use PyPI, since that makes it more accessible and easier to maintain.

Alternatives

• Loading the package on the robot manually - doable, but impractical/inaccessible for some FRC teams, who may have never even heard of SSH.
• Manually downloading the wheel and storing it in the pip cache, leaving it out of the pyproject.toml - gets around the syncing issue, but also doesn't install the package on deploy.
• Directly naming the wheel using linux_roborio - PyPI doesn't allow this
• Adding another search index that does allow linux_roborio - still requires changes to the installer, and may add costs to individuals for hosting. Also creates a decentralization and trust problem.
• Storing it in the special WPILib index - This seems like it could get out of hand quickly if you did this for everybody that asked, though it's probably the most reasonable alternative

[PeterJohnson]

Unfortunately, RoboRIO is unique in that it uses the softfp ABI, and I believe manylinux_armv7l assumes the hardfloat ABI. So anything using floating point would be silently broken at a minimum.

With only 1 season of RoboRIO left, this is a short-term problem. Systemcore should work fine with standard manylinux aarch64 binaries.

[virtuald]

Yeah, as Peter said, if we could have used the armv7l tag originally then I would have went that route. My strong preference would be to make it easier to manually install packages. Currently it's tedious at best, and makes it hard for developers (even myself) to test on real hardware.

We also have https://github.com/robotpy/roborio-wheels which builds wheels for roborio and uploads them to our special wpilib index. However, it doesn't support rust -- but mostly because I don't have time and I'm not familiar with rust. It might make sense for you to add rust support to that repository -- we're happy to accept builds for anything that the community needs.

[KellenWatt]

Thanks for the comments!

I went with the most obvious route first, which was the installer, but I'll take a look at roborio-wheels to see if I can make that work! If not, I'll make do with manual installation for this season. I wasn't aware of the RoboRIO going away (I live under a rock wrt to FRC), and I don't see myself widely advertising this in the near future without a season to test it.

[virtuald]

There are other packages that people wanted that needed rust support, so adding support to roborio-wheels would certainly be welcomed.