Python 3 image

[VoliKoN]

Since Octoprint 1.4.0 supports python 3 and python 2 is EOL, we should really use python 3 in this image.

There is maybe one problem with plugins not yet runnable on python 2, but aside from that it should be an easy fix.

I will try to make a pull request but I'm not sure I'll have enough time...

[nunofgs]

Good point. I haven't had much time to play around with the image but I'll be getting back to it soon, and will shotgun-fix a bunch of stuff in one go. I'll make sure to test python3, especially with older plugins.

I haven't decided on whether to migrate to python3 and accept any breaking changes (and possibly breaking some plugins) or to keep a python2 image as backup.

Any thoughts?

[VoliKoN]

You could probably do a tag for every python version, and keep latest on py2 until most plugins will support py3.

[MatthewCroughan]

@nunofgs One of the main uses of docker that I try to utilise is a sort of rollback of stateless elements in an image, such as the Python binary inside the container, or the files in /etc/, whilst keeping everything inside your mounted volume such as /data/ the same. If the image and application is properly architected, then the stuff in /data/ should not be storing stuff that is dependant on Python3 or Python2.

In your scenario, you should be able to simply use your version tag nunofgs/octoprint:1.3.9 and that rollback would be complete. It's probably best to say that Octoprint 1.3.9 was the last valid Python2 edition of Octoprint. Though I am finding that actually a lot of stuff in /data/ is quite necessary for some reason, and this kind of a rollback isn't possible. What is it that is stateful that makes this kind of rollback impossible?

For example, I clicked the "update octoprint" button in the Octoprint web interface, knowing that this would not work but was expecting that it would not break the application. What happened was that Octoprint modified a bunch of stuff in /data/ that would of course be persistent since there is a persistent volume in this docker image that keeps changes in that directory persistent. There is something in /data/ that then causes breakage with Python2. This should not really be the case.