Migrating existing installation(s) from Python 2 to Python 3 on Ubuntu (Server)

General
1

I'm running two instances using systemd. I know this is not supported, but it works fine for months now.

I just wanted to describe on how I'm planning to do this and if maybe someone sees something that could be an issue, maybe give me a little hint?

I'm the author of these guides:
https://makenotes.de/2019/09/octoprint-on-ubuntu-with-systemd/
https://makenotes.de/2019/12/multiple-octoprint-instances-using-systemd/

I would also update these guides accordingly or add another one for the migration process, so others can benefit from this.

Current version is 1.4.0 running with Python 2. Configuration and data files are in /home/octoprint/.octoprint1 and /home/octoprint/.octoprint2

1.) First, I would stop the currently running processes (in my case using systemctl).

2.) Make sure Python 3 and pip is installed (something like apt install python3 python3-pip python3-dev python3-setuptools git build-essential)

3.) Upgrade local pip3 and then run pip3 (in my case as the system user running OctoPrint) to install OctoPrint in its local directory:

pip3 install --upgrade --user pip
...

which pip3
/home/octoprint/.local/bin/pip3

pip3 install --user octoprint
...

4.) Make sure, that (in my case) /home/octoprint/.local/bin/octoprint uses the #!/bin/python3 shebang and/or make sure that the octoprint script is started with the Python 3 executable (/bin/python3) - in my case in /etc/systemd/system/octoprint@.service

5.) Restart the service(s) (systemctl start octoprint@1.service octoprint@2.service)

6.) Re-install the Python 3 plugin packages (if available) using the GUI. List them with something like ls -ld ~/.local/lib/python2.7/site-packages/octoprint_*
Or install them using pip3?

I'm aware that this is "dirty", since I run multiple instances and both share the same local Python libs.

2

I strongly advise against global (or user) installs and instead go with the virtual environment approach from the official installation guide.

That's also what I put into the migration guide (which current us focused on plugin developers since the average user won't be very happy with a python 3 based OctoPrint instances due to most plugins in the ecosystem not being compatible yet). See here:

https://docs.octoprint.org/en/master/plugins/python3_migration.html

1 Like
3

Ok, thank you!

I will check out virtual environments. Although I'm running this setup for about a year now and never had any issues. Still, I'm sure you have perfectly good reasons to advise against it.

For now, I've done like I described above. Since I don't really need any plugins, only the core functionality, that's not an issue.

4

Yep, and just to elaborate on that...

The issue is that any kind of global or user wide install holds a risk of dependency problems. As long as you only have OctoPrint running on a given system/a given user, there should not be an issue (though gobal installs under Linux tend to run into issues with dependencies installed via the system's package management vs natively from Python), but as soon as there might a different tool or app or whatnot installed in the same place things can get REALLY awkward.

A virtual environment allows isolation of OctoPrint & dependencies from whatever else you might have installed with regards to Python, and thus provides a way more controllable and thus stable and functional runtime environment.

5

Thank you for your detailed reply! :slight_smile:

I'm currently testing this, using venvs, and it seems to work at the first attempt also using a systemd service and a dedicated user account. Somehow I wasn't expecting it being so easy... But it seems the fact, that the Python interpreter has build in support for this kind of environment makes this easy or at least transparent for other users/software.

The plugin manager also shows the new environment and the pip version used. I was just wondering why it still says "Virtual environment: no"? Not that this would be an actual issue...

Screenshot_20200314_111824
Screenshot_20200314_111824776×209 14.7 KB

6

You might want to visit OctoPrint -> Settings -> Server to adjust the system commands if you've changed things from init.d to systemd. In most cases for this to work, you need to create an accompanying /etc/sudoers.d script to allow the pi user to actually run whatever you're suggesting here.

Also, it's important to have OctoPrint run within that virtual environment you created.

ps -ax|grep octoprint
/home/pi/oprint/bin/python /home/pi/oprint/bin/octoprint serve --host=127.0.0.1 --port=5000

That path to python includes the oprint virtual environment in my case.

7

Thanks for the reply! I think I pretty much covered that already in my previous articles (see above).

Based on these, I've created a new one, using virtual environments and an update systemd unit template file:
https://makenotes.de/2020/03/octoprint-on-ubuntu-with-python-3-virtual-environments-and-systemd/