Ever had a tough time working on code because a computer isn’t setup with wpilib tools and you don’t have admin permissions? You don’t need it anymore!
You can now compile or modify your robot code (with intelisense!) using github Codespaces. Before we start you should note that there is 60hrs free of 2 core codespaces per month and even if your project is under an organization it will be charged against your account, NOT THE ORGANIZATION. We have made a example of this on our mentor example code on github.
You can delete codespaces after you’re done with them by going to Code->Codespaces->On current branch->...->Delete.
To create a codespace you go to Code->Codespaces->Create codespace on main.
Codespaces seem perfect for teams where not all programmers have their own laptops and can install the tools on them. To set it up for an FRC project all you have to do is create the file from the root of the repository .devcontainer/devcontainer.json which contains
Cool stuff! This certainly can also be helpful for students working off of school provided devices, which commonly have draconian limitations (usually on installations, but less so on specific sites). Team 5113 is working on an analogues system (based on the “thin client” archetype), hoping to report back soon!
Does the image you use support viewing the sim gui?
Gitpod has a similar number of free hours and one of their base images comes with automatic browser based vnc if a gui is launched. Using a similar image on codespaces would be invaluable.
Regarding the plugin installation, I’ve heard that having the WPILib plugin live in the plugin store may or may not continue (@Thad_House ?). If its not available, this may require some changes here in the near future, and maybe a simple docker container.
We publish it to the store just so someone else doesn’t publish an unofficial version with the same name. We don’t monitor or maintain the store version because we recommend teams use the WPILib installer’s version of VS Code instead. We do that because the installer must modify the VS Code install to make intellisense work. In other words, using a vanilla install of VS Code with the store plugin is broken due to Gradle-isms.
Out of curiosity, and sorry for pulling the thread slightly of topic, what kind of of modifications does it do to the VS Code installation itself? I looked in the installer repo but am not familiar with the layout. (You meant the Avalonia installer, not the plugin, right?)
EDIT: I found this, so it looks like it’s specifically things in the user settings file?
It seams to be done with whole desktop interface here which uses NoVNC to show it to the user. Probably something can be implemented for FIRST based applications as well.
Interesting. Our team, has used both the installer version and a normally installed version with a current version VSIX from the GitHub project. We didn’t notice a significant difference, but maybe we weren’t looking hard enough. Is there a list of changes made to the basic VSCode that we can see?
Seems odd that this would be enough (especially because the JDK is just temurin11), are those changes the only ones necessary to get InteliSense working and fix the aforementioned “Gradle-isms”?
There’s nothing related to IntelliSense needed for a vanilla install vs the wpilib install, other then the forced jdk, which sometimes can break IntelliSense.
The primary reason is to force a known good jdk, as well as disable updates and disable system certs as said above.
Forcing a known good jdk was very important the first year, and is still important as invalid jdk versions (both too high and too low) can break builds.
Disabling updates is important because there have been cases in the past where vscode updates have broken the extension, which is hard to debug, and really annoying on our end.
The certificate thing is probably not as necessary anymore, it was added a few years back when sites were changing tls versions and that broke things.
These things, plus the local maven cache are the main reasons we really recommend the installer. It limits the amount of configurations we need to support.
I understand where it coming from but in the same way, u know some people are going to prefer using vanilla VScode and it would really be super basic to continue to update the extension store. You can still put in the description that it’s recommended to use the WPI version of VScode with still making the extension more accessible.