With 2022 being a control system update, at WPILib we’re planning to use this to make some long needed improvements, and I’m focusing on the build system side of all of this.
We will be keeping VS Code and Gradle for 2022. Improved simulation support on both ends is the biggest improvement being made that will be visible to users. However, in the backend, all the deploy functionality is getting improved as well, and getting a complete rewrite as we’re moving all the plugin code from being groovy based to being Java based. Some of these changes do slightly change how the build scripts are set up (they’re a lot easier to understand now), but this gives us the best time to bring in new features.
Because of this, are there any changes users would like to see to either the VS Code side or the Gradle side for improving their experiences? Now’s the time to do them, as everyone has spent a few years with the current setup. Just post your comments here and I’ll look into them.
We already have a few that are being planned.
Better Docs
Better simulation support (support release mode, support default and non default enabled extensions, show names instead of library names in vscode)
Tasks to read files off of the roborio during deploy
Stages for deploy, to enable manipulating the deploy pipeline much easier
Disclaimer: I’ve been contributing to GradleRIO for a while.
Another question that we’ve run into: should unit tests be run on deploy? If yes, deploys will likely take a bit more time and failing tests might fail the deploy.
I would like to see better integration with the VS Code Live Share plugin to allow building and deploying from client computers. I realize executing code remotely is pretty iffy, but it’s been a bit inconvenient to have to tell the person hosting the session to hit build if someone else made a change.
I think that a built-in, opinionated code-formatter would help a lot. It’s easy to do if you know that they exist already, but for many new programmers, they don’t. My students have said that using Java formatters have helped them a lot over the last couple years since we started using one. It would probably help out CSAs quite a bit too for debugging.
I’m not sure if its possible for Gradle to auto-format on build.
We unfortunately don’t have any control over that. Additionally, that brings up a whole host of concerns about safety. What if you deploy bad code, they don’t realize it was deployed, and someone gets hurt? A bit far-fetched but the possibility is there.
Code formatters can lead to unpredictablity. Teams can add Spotless to their Gradle project pretty easily already. I don’t think it should be the default here.
I said that it’s easy if you know what you’re looking for, but many don’t. I enjoy helping out teams with less programming knowledge than us but it’s a massive headache when their code lacks any formatting at all.
I’m a professional software engineer and I didn’t know Spotless existed we just manually ran something from the command line every time. Knowing about spotless would have saved some headaches!
Rookie teams with spotless being forcibly applied will encounter some hindrances. The code they write will not appear as the same as the code that gets checked in (if their using version control).
We could absolutely document usage of code formatters for teams. We already document CI usage for teams just to test that robot builds.
One of the big issues with formatters is handling line endings. They are all pretty much universally bad, especially because windows and linux have different default endings. This is a nightmare if you don’t know how to configure it right. Also, C++ doesn’t have a fantastic format setup. Ours we use in WPILib is a giant monolith that requires external programs to be installed and very particular setup.
I don’t think thats a great thing to be built in by default, but am 100% in support of having some documentation on something like that.
I think this one would be cool as well, but iirc I don’t think the Live Share API gives us access to a remote console. I’d have to look. That would be required to make live share work.
As a solution, I think you can expose a remote console over live share. If you can do that, you can just call ./gradlew deploy from that remote console.
I do not know enough about either the inner workings of WPILib or how other companies function, but anything that can be done to make extensibility and implementation of new features easier for 3rd party vendors would be amazing.
I see many threads about things like using Rev CAN (or until recently CTRE) in the simulator or the VMX-Pi with 2021 libraries, and the fact that we have to wait for those implementations does create some confusion.
As far as the simulator is concerned, it would be amazing to have the ability to run something like the robot wizard to create a simulated robot with all the mechanisms and all. I guess that is a tall ask though.
I cannot say how much our team appreciates all the upgrades to the 2021 library. The install is as close to one-click as possible. From first install to trajectory following, the documentation and examples are clear and extremely helpful. Also, the Romi are the perfect practice and at-home learning machines.
I’d like to see better support for online IDEs like gitpod. I’ve tried getting a simulated environment working in gitpod with some success, although the vscode wpilib extension doesn’t seem to work. I was able to run the gradle commands to build and simulate code in the terminal, but it still would be nice to have.
side note, how are you getting live share to work while connected to the robot? are you deploying over USB or do you have an access point set up so you can deploy while still connected to the internet?
Currently, I have a wireless bridge set up to connect to the robot’s router plugged into the computer’s Ethernet port and I use my home WiFi to connect to the internet. Previously, I connected directly to the robot through the laptop’s wireless card and used my phone’s USB tethering to connect to the internet.
Command-based has long been desirable, but gets daunting for the full robot project (I always have an easier time falling back to iterative/timed robot). I think a fuller set of examples of what a complete project with a wide variety of controls looks like i.e. joystick axes, button controls, sensors triggering actions, etc. I think the docs mention these all in isolation, but seeing one all-together example would be helpful.
RobotPy did ran tests by default for many years and nobody ever complained that much about it (probably because it had a flag to skip tests if you’re in a rush). Our students learned to not skip the tests unless they ran sim first as they would invariably mess something up when they did.
We can likely set a flag in the test config to not fail the entire build if tests fail- that’ll solve one issue, but then it’ll be less obvious if tests failed.
I think that parallel gradle workers are a thing, so perhaps we can get the tests to run in parallel to the deploy. That’ll reduce the additional time that running tests would take (but it would still exist).
Regarding formatting:
Spotless has a flag that causes it to not fail the entire build. Spotless docs are very informative, so we can point there. We can provide an example build.gradle with spotless that showcases a “don’t fail build” flag (it exists). Or we just cause deploy to apply spotless and be done with it - and this goes back to what Thad said about making the deploy pipeline configureable.
we just manually ran something from the command line every time. Knowing about spotless would have saved some headaches!