autopilot
autopilot copied to clipboard
Terminal having dependency issues
When I followed the instructions to install and setup a terminal (in a virtualenv), autopilot wouldn't launch, saying that I was missing PySide2. I managed to install it (using apt), after which it was missing pyqtgraph, which I installed with pip, and now it's missing shiboken2 (which I installed with apt, but it doesn't seem to be working).
I'm thinking I did something wrong, is there something else I should have done to get these dependencies? I'm using raspbian default + virtualenv + latest autopilot from main, happy to switch to a different setup if it's better supported.
Just to check ... are you trying to run the Terminal on the Pi itself, or on a standard desktop computer? My understanding is that the Terminal is meant to be run on a desktop computer (or laptop.. not a Pi though). Since you mentioned raspbian, I'm wondering if you're talking about the Pi (which should be running the Pilot, not the Terminal, if I'm not mistaken).
related to: https://github.com/wehr-lab/autopilot/issues/114
Dependencies, and particularly optional dependencies are a managed in a way that i'm not very happy with at the moment. Chris is right that typically the pis are not intended to run the GUI, but working on relaxing that limitation, because the notion of "agent" shouldn't be fixed to a particular machine (but particular machines do have particular abilities, eg. GPIO on Pi) -- basically those concepts need to be decoupled.
how dependencies are handled now
in setup.py...
- there's a system check to see if the CPU is the broadcom chip used in the pi: https://github.com/wehr-lab/autopilot/blob/e5578c47d22c5a90b194e61133d193c85597a76f/setup.py#L30-L36
- then a check for cpu architecture: https://github.com/wehr-lab/autopilot/blob/e5578c47d22c5a90b194e61133d193c85597a76f/setup.py#L39-L47
- which then selects a
requirements.txtfile to use: https://github.com/wehr-lab/autopilot/blob/e5578c47d22c5a90b194e61133d193c85597a76f/setup.py#L62-L75
That's for python dependencies. System dependencies are different and harder. for that there's a notion of scripts (sorry haven't figured out a good way of generating documentation for that yet, you might be better off with the source)
why that is bad
- implicit
- not very configurable (actually not configurable at all).
- no way to install dependencies later or check which have been installed from within the package
- very coarse notion of dependency specification, this is especially problematic for when it's time to actually finish implementing dependency management for plugins
- system and python dependencies specified separately
- different requirements files can get out of sync and are hard to maintain
- no notion of testing for configuration, eg. in case someone has changed some system configuration value that we expect to be different from running a script, there's no way to tell.
what to do for now
Have you gotten it running yet? I typically don't advise installing python packages through apt, especially with the raspi the repos can run pretty far behind, and they're tricky to use within virtualenvs. PySide2 is actually refreshingly simple to install, PySide was a huge pain in the ass that needed a bunch of special code. To install all the packages that the terminal uses, you might try pip install -r autopilot/requirements/requirements_terminal.txt which has pyqtgraph and PySide2. You may have conflicts between apt/system PySide2 and venv PySide2, depending on how you install it, so feel free to ping back here if you run into problems.
what i think we should do in the future
- I've been using poetry in a few projects and loving it! much more sensible way of pinning dependencies, managing versions, and making optional dependencies.
- That handles the python dependencies but not the system dependencies, but I think that we can build on the notion of the
.lockfile by having anautopilot.lockfile that tracks all the packages installed in a particular environment, the different groups of dependencies (eg.guivs.sound) that are installed, the different scripts that have been run, and maybe even certain environmental variables. There isn't really a way to specify system dependencies in Python (and arguably there shouldn't be), so we'll have to keep scripts (i think).
why that would be good
- making dependencies a lot easier to manage programmatically (so eg. a plugin can specify dependencies and autopilot knows how to get them)
- makes
~provenance~a lot easier too -- currently we manually handle different pieces of that (git hash, etc.) but it would be way easier to have a single.lockfile that could be zipped up and saved at will - makes
~replication~a lot easier --autopilot.setup.lock --install lockfile.lockcould try to reinstall a whole autopilot environment from one file. - gives a declarative statement about how the environment should be, so if eg. a system configuration value is changed, there's something to check it against, instead of just the script that changed it in the first place.
so, good issue! it's been a major point of brittleness for awhile! i tagged it as a milestone for v0.5.0.
also to be clear! happy to hear other ideas, dont want to be a dictator, now matter how benevolent i think i am, and as always if anyone feels the urge to try and clean up packaging at all, would love a PR :)
Thanks for your help! Yes, I was trying to install it on a pi - I assumed it was meant to be, and I don't have a linux PC handy. However, I was able to install it on WSL - it seems to work so far. I had to do a little work to get the GUI working, but I think that's mostly a Windows 10/WSL issue that's been fixed in Windows 11.
As far as pi compatibility, I tried to install everything with pip before resorting to apt - if I'm remembering correctly, it couldn't find PySide2.
Aha, yes i see now PySide2 only has binaries built for x86_64: https://pypi.org/project/PySide2/5.15.2/#files
I think you'd need to build it from source to use on the Pi, they have instructions here: https://pypi.org/project/PySide2/ and if that would be useful I can add them as a script?
Good to hear it works on WSL!! ('m a little surprised, nice job windows!) If you recall what error it was/how to fix I can add it to the docs/wiki :)
No errors with WSL, but on windows 10 it doesn't support a GUI out of the box, so I had to install and configure an X server for Windows, following these instructions - https://techcommunity.microsoft.com/t5/windows-dev-appconsult/running-wsl-gui-apps-on-windows-10/ba-p/1493242.
OK! added that to the wiki <3 https://wiki.auto-pi-lot.com/index.php/X_Server_on_WSL