What will be the process to upgrade a VirtualEnv based Octoprint to Python 3?

As we prepare for a Python 3 world, not being a python expert at all, I am wondering what I'll need to do to upgrade my Octoprint directory that's set up using VirtualEnv & Python 2.7 (which I am guessing most non-Octopi people are using to install Octopring?).

I couldn't tell you what the recommended method is but I've spoken about this before on here. Note that the 10th step is likely something else. The devel branch is whatever new work is being done. Usually at this step, you might stop and do a git branch in that folder and see what branches are available and to use something like that instead of devel.

I agree. Once the 1.4.0 version is officially released, this would be the version you would want to install. Currently it's on RC3 and probably will be released shortly after the first of the new year. My assumption is that once that version becomes stable release @guysoft will potentially be updating his octopi images to default to python 3, maybe. There's still going to be a lot of plugins that haven't completed python 3 compatibility upgrades though that will also have to be accounted for.

I'll actually tell him to hold off on that for a while longer due to the plugin situation.

To answer in the question in this thread - you don't update the virtualenv, you create a new one and reinstall OctoPrint into that.

Thanks @foosel (just signed up for the Patreon, been using Octoprint for a year+).

When you resintall Octoprint into that new Venv, how do you bring in the settings and history?

2 Likes

Use the backup/restore options in settings. Pretty sure the settings will still read from the same .octoprint folder for config stuff, but you'll have to still reinstall the plugins you've installed, which the restore process will handle. Again, many plugins haven't been converted/made compliant yet with Python 3, so they will not load by default without some tweaking to config.yaml or a plugin update.

The new virtual environment—installed OctoPrint will use the original ~/.octoprint—stored configuration files. In my experience the new Py3/v1.4 code wants to change some things there (like the user.yaml file?) so you may want to back that up, mark it as pre-Py3 so that you can revert if necessary.

Or better still, just backup the microSD by cloning it.

I'm willing to help plugin authors migrate to Python 3, as long as their code-base isn't huge. Just got finished making Octolapse work (including the C++ libs), and it wasn't too bad. Well, except for the insane string/bytes crap. That will probably never work on both python 2 and 3 perfectly at least on my plugin.

Also, surprisingly, I've noticed a performance INCREASE with python 3. My preprocessing routine is about 50% faster on Python3, which I did not expect. I haven't tested it on the PI yet, so it may not hold.

2 Likes

I'm scared of the increase in bug reports myself once people start actually using my plugins in the upgraded python. I thoroughly tested prior to releasing my compatibility updates, but I'm always afraid of some use case I didn't think of. Luckily the majority of mine are front end ui changes, but the most popular (bed level visualizer) does have quite a bit of python.

Well, you don't have to handle them all if you don't want too, lol! Seriously though, once we get through this switch we'll have access to a MODERN version of the language. From what I see, most of the things I've found so painful in Python 2 have been addressed in Python 3. Also, once support for 2 completely vanishes in OctoPrint, we can take out all of the backwards compatibility crap, and that will be nice too. I'm more concerned about backwards compatibility than Python 3 compatibility honestly. I hate testing in two versions of Python AND multiple OS. It literally doubles the work. I guess I should have done real unit tests, lol!

:fast-forward to the year 2040:
:a coder is staring at a screen:
1st coder: "What's this do?"
2nd coder: "Beats me, better leave it just in case..."

1 Like