As much as I’d like to run straight linux and be done with it, the driver station and other utilities don’t have a linux version… which pushes the coding effort onto Windows. I suppose I could have two LTs; a linux box that does the deploy, and the driver station runs windows. Have people tried/done that? Any pros/cons?
But the reason for my message:
I installed Windows Subsystem for Linux (Ubuntu) and notice that when I try to deploy (python3 robot.py deploy), I see the following behavior:
Unfortunately, I use Windows very rarely so I don’t have a good answer for you at this time. I generally don’t install development software on the DS either.
Generally speaking, I find that if I install a python package using the interpreter that I’m using at the time, that it will be able to find it later on. The best way I’ve found to guarantee this is via
[python executable] -m pip install ...
As opposed to executing the pip.exe directly.
One way to find out where something is installed is to open the python interpreter, import the module you’re interested in, and print(MODULENAME.file). That will give the path.
I have historically found that running ‘py’ instead of python3 on Windows gives me better results. I’m not sure how that interacts with WSL.
Not sure about the powershell problem, but the WSL problem is likely due to the fact that WSL uses a different python binary (and as a result, a different pip binary) than cmd.
C:\Users\Justin>where python
C:\bin\Python36\python.exe
C:\Users\Justin>bash
Justin@Justin-Desktop:/mnt/c/Users/Justin$ which python
/usr/bin/python
Gixxy led the programming that way in 2012 and 2013, using a Linux laptop for development and the clamshell (Classmate) for a driver station. Other than the need to connect a different computer for testing vs loading, I don’t recall him having any difficulties. Using a separate computer for the driver station also allows the programmers to keep working during drive practice (and matches at competition). AFAIK, 3946 still uses a separate driver station most of the time, even though the development system is Windows.
With Ctrl-c not stopping things in Windows, I’ve found that it does actually work, with the caveat that for anything listening to the network, it has to actually receive something from the network before it’ll handle a Ctrl-c.
Ctrl-Break is a thing on Windows too apparently. I haven’t had a chance to try that instead.