search

nunofgs / docker-octoprint

Dockerfile to set up Octoprint with x86, armv6, armv7 and arm64 support!
https://hub.docker.com/r/nunofgs/octoprint/
GNU Affero General Public License v3.0
58 stars 32 forks source link

Python 3 image #39

Open VoliKoN opened 4 years ago

VoliKoN commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

MatthewCroughan commented 4 years ago

@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.