Migrating plugins to Python 2 & 3 compatibility - experiences?

[foosel]

@OllisGit

OctoPrint API-Breaking changes (maybe not the right words)

The thing is, I made it a conscious effort not to have any breaking changes on the API. What you are referring to here isn't a breaking change in OctoPrint, it's a breaking change in Python 3 that affects a helper class provided by OctoPrint as that inherits from a core Python class. I'll make a mention of it in the bytes vs string section though to give it some more visibility. It's also the only thing that I'm aware of at present.

edit Added:

@OutsourcedGuru

I would say that most of us begin with an OctoPi-imaged rig and modify it for Py3.

I sincerely hope that that's not how most plugin developers start given that the tutorial explicitly walks people through setting up a proper local development environment. Developing directly on a Pi is just painful.

I also make it a point to start OctoPrint manually from shell in the migration guide, in the corresponding venv, via the octoprint executable. I'd rather not want to confuse people and start with OctoPi details there, especially not since the guide isn't about how to migrate your OctoPi image to using Python 3, but rather how to migrate your OctoPrint plugins to Python 3... I'll think about adding a footnote though.

edit Added, and not as a footnote:

[BillyBlaze]

Things I had todo for TouchUI.

First off; migration docs where helpfull!

Second, this is what I had to fix:

1. basestring no longer supported, update crossdomain decorator (/w backwards compatibly) with the following

try:
  basestring
except NameError:
  basestring = str

2. Hashing now requires encoding:
   Old: hashlib.md5(contentFile.read())
   New: hashlib.md5(contentFile.read().encode('utf-8'))

That was it for me.

[b-morgan]

@foosel, I just tried to follow your Migrating to Python 3 and I'm still a little confused...

I have a working OctoPi 0.17.0 / OctoPrint 1.4.0 with installed plugins. I believe this "virtual environment is "~/oprint". I have created a venv3, activated it, and installed OctoPrint.

Maybe I'm too old to read between the lines but the next step is, "create an editable install of your plugin, start the server and start testing" and for me, that leaves out a step (or more) before like "shutdown your current OctoPrint environment" and maybe a step after "to return to your original OctoPrint environment".

I think maybe the second note (If you want to migrate your existing OctoPrint install) might be more relevant to what I am trying to accomplish, have both environments available and switch between them as needed. Adding the "switch" commands would be very useful, IMO.

[OllisGit]

For my new Version of DLP I need to handle different import-statements. My solution looks like this:

import sys
is_py2 = sys.version[0] == '2'
if is_py2:
    import Queue as queue
else:
    import queue as queue

@foosel Maybe it could be a part of the offical-doc...MergeRequest against this branch, right? https://github.com/OctoPrint/OctoPrint/blob/40a0913fa440e8c9618184729d27145f13a3f846/docs/plugins/python3_migration.rst

[foosel]

Personally I'd rather recommend this pattern:

try:
    import queue
except ImportError:
    import Queue as queue

See also

Migrating plugins to Python 2 & 3 compatibility - experiences?

Took me way too long to get back to my own topic thanks to the new RC - sorry for that You can actually skip a ton of these steps - or at least it worked fine on my end to do that... virtualenv has an argument --python with which you can specify the Python interpreter with which to create the venv. So it boils down to installing both 2.7 and 3.7 somewhere and then telling virtualenv which interpreter to use: virtualenv --python=C:/Python27/python.exe venv27 virtualenv --python=C:/P…

But yeah, it might make sense to add an example of that to the guide. maintenance branch, path was correct.

[OutsourcedGuru]

Dear Santa,

For Christmas I would like both Python 2 and Python 3 to have identical imports for queue.

Thanks,
OG