I just updated the wiki you linked with something that should probably work, though I haven't been able to test this in person.
can confirm the new guide works as it should, but side note, the following is an incorrect command
"pip install --upgrade setup tools" should be "pip install --upgrade setuptools"
is there anything i need to do to run under python3 specifically?
1 Like
Fixed the typo.
For python 3 pretty much the same steps, just with --python=python3 on the virtualenv creation. Though I'm not sure what you need to do (or if you even need to do anything) to get python3 setup on the BBB in general. Also keep in mind that while OctoPrint is now python 3 (or rather 3.6+) compatible, most plugins aren't yet.
1 Like
I typed this out before server maintenance(?)
I have OctoPrint installed systemwide on my Orange Pi 3, and daemonised.
I just fixed mine by changing in /usr/local/bin/octoprint "python" to "python3" and sorting the rest with "sudo -H pip3 install octoprint".
Let it do it's thing then "sudo service octoprint restart"
Server came up again.
The mention in the thread about Python versions prompted me to check.
You also have a global install. Global installation is not recommended. It just causes all kinds of issues. The official installation guide has instructed to create a virtual environment for years now.
I guess from a support standpoint we ask the user to run:
which octoprint
... or ...
sudo find / -name octoprint 2> /dev/null
...and if it's not something like /home/pi/oprint/... under the pi user's home directory (but not .local) then the user has a global OctoPrint install. :cue the South Park ski instructor:
Maybe a blog post on global installs or appending to the existing blog entry...?
I frankly don't want to prepare, review and push out a blog post about something that's not even to be found in the official installation guide anywhere.
But what I'll look into is why OctoPrint isn't outright refusing to update in such broken-by-design setups, like it should. That should avoid this in future versions and force users to either fix their installs or update manually.
1 Like
I spent a few minutes to fix mine. Because it was already using a user specifically created for the purpose it wasn't hard to setup a venv install and alter the /etc/defaults/octoprint to suit.
I do however have a concern about the lack of mention on how to configure privileges for octoprint service restart. Is it even possible without exposing the full functionality of "service"?