I figured I'd go on the record somewhere now due to stuff like
making this seem a tad urgent.
As said in various OctoPrint on Air episodes, OctoPrint 1.4.0 will support Python 2 and 3.
Plugin authors are advised to test their plugins for compatibility with Python 3 against
the the latest 1.4.0 Release Candidate of OctoPrint (currently 1.4.0rc3). To do that install Python 3, install OctoPrint in a Python 3 virtualenv, set the control property
devel branch of OctoPrint (1.4.x)
__plugin_pythoncompat__ of your plugin to
>=2.7,<4 (the default is
>=2.7,<3) and install it into the same Python 3 virtualenv. Test it thoroughly.
If your plugin works as expected, everything is fine and you can keep the control property and also file a PR against the plugin repository to update the listing of your plugin by setting
compatibility.python in your plugin's registration to
>=2.7,<4 as well:
compatibility: python: ">=2.7,<4"
That way it will also show as compatible in OctoPrint 1.4.x's plugin manager.
If your plugin doesn't work under Python 3, you probably want to take a look at this cheat sheet to help you fix it.
If you run into any kind of OctoPrint issues while testing, please open proper tickets for them!
Going forward, your plugins should (ideally) support both python 2 and 3 until OctoPrint drops support for Python 2 (which by current planning it won't do until version 2.0.0 since it will mean backwards incompatibility). This also means keeping an eye on third party dependencies you are using!
Now for some bad news. The new comm layer has made huge steps forward, it prints reliably for me and feature completion is almost there. But with it pretty much now being October and 1.4.0 having to be released until 2020 due to the looming Python 2 EOL date it won't make it into 1.4.0 but will have to wait until the next feature release.
I've thought long and hard about this decision, and it honestly sucks, but it is simply too risky to push it out now since there won't be enough time left until January 1st 2020 to give it the overall testing by me and the community that such a crucial part of the software needs.
The new plan is to prepare a first RC of 1.4.0 ASAP and then merge the new comm layer into the new 1.5.0.dev version of the
devel branch that will then get created - which btw might also end up as being rebranded as 2.0.0. That way those people running the
devel branch will be able to test it and provide feedback and I don't have to worry that some issue in it nukes the pre-2020 release of 1.4.0.
From a risk management point of view that simply makes more sense, even though I can tell you I really would have loved to finally put an end to this chapter (especially since as long as it isn't merged to stable I get to do everything relating to the comm layer twice, in the current and the new one).
That'll be all.