Looks good:
Though of course the date would need adjustment, and you probably also want to change the feature list 
One important thing: Due to the EOL of Python 2.7 on January 1st this year and the needed migration I'm no longer accepting newly registered plugins into the repository that aren't compatible to both Python 2 and 3. So you'll need to test for that and mark up your md files and plugin itself accordingly. Take a look at
for some hints and discussion on the topic.
Hi @Kragrathea,
I was also struggling starting the jekyll server and using the right git-commands as well.
My solution was to execute just bundle for some kind of initial setup. After that I could execute the server as described in the documentation bundle exec jekyll serve
I wrote a short wiki page for that in my knowledge base:
Thanks foosel!
Python 3? Yikes. I'll have to look into that this weekend...
I took a quick look at the doc(s) for what is involved in the Python 3 change and it looks substantial. According to the Python2 - > 3 "cheat sheet" It looks like lots and lots of little changes to the python code. Some are clear like () around everything but the changes to exception handling and imports are much less so. I started with some plugin template. Is there a Python 3 version plugin template now? It might be better to start over.
And is it correct that the only way to test a plugin is to install Python 3 and build a virtual machine version Octoprint on Windows? I have just been remote accessing my Pi.
@Kragrathea - I have just had a quick look at the source code, and it all looks Python 3 compatible, so I don't think you have to worry (as there is not much Python, it was an easy check). I have not yet fully run it with Python 3 (have done an import and flake8 test), but I think you'll be OK, so I would move on to the next stage
Personally, when I do Py3 compatibility testing for my own plugins I make sure that I'm doing all this on the Raspbian platform right on the Raspberry Pi 3B (or 4B).
A variety of things which are installed for a plugin (like dependencies) are compiled from source. This means that it may behave differently on different operating systems and hardwares (slightly, one would hope). For this reason I believe that it's crucial to test on the intended hardware. (So testing on Raspbian Buster Desktop would be different than testing on Raspbian Buster Lite which would be different than testing on a Windows-based PC, in other words.)
In my own work, I see that...
list() as I recall for the interface I expected from Py2.print "hello" syntax but that's changed to print('hello')
== comparisonsGood grief! Given all those changes, even if MY code uses very little Python, the underlying systems of Octoprint that my plugin DO use could change. Things like the Int/Int = float and the unicode strings come to mind. Ug.
I am glad I can actual test on a real Pi. How do I force my plugin to use P3?
I've not used it but there's a transpiler of sorts for all this:
https://docs.python.org/3/library/2to3.html
Also, I forgot one earlier. Code which looks like
from myfile import Whateveris reasonably broken. Py3 doesn't love it if you don't decorate the path to your own files. Presumably anything without a path is considered to be part of Python itself. So those would need to be converted to something more likefrom .myfile import Whatever(minimally).
Forcing your plugin to use Py3 means removing/replacing the underlying virtual environment. But this means then that you need to reinstall OctoPrint itself to that new Py3 virtual environment.
sudo service octoprint stop
cd ~
rm -Rf oprint # Perhaps a safer option is to rename it instead
virtualenv -p python3 oprint
source oprint/bin/activate
python --version
pip --disable-pip-version-check install https://github.com/foosel/OctoPrint/archive/1.4.0rc4.zip --no-cache-dir
sudo service octoprint start
# Visit the web interface to make sure it's happy
cd ~/MyPlugin
python setup.py develop
sudo service octoprint restart
tail -f ~/.octoprint/logs/octoprint.log
I use rsync to push the entire folder structure over from my laptop development folder to the Pi. I then do the following on the Pi each push cycle (making sure I'm still "sourced" in that virtual environment):
cd ~/MyPlugin
python setup.py develop
sudo service octoprint restart
tail -f ~/.octoprint/logs/octoprint.log
But of course that's all done from alias commands that I have in my ~/.bashrc to save typing.
Thanks OutsourceGuru! Unfortunately, that means I am going to have to table this for the time being. I have my OctoPrint and all my plugins setup just the way I like it and I don't want to risk messing it up right now. My printer is going 24/7. :-/
Do you have any idea when we expect the Python 2.7 plugins to stop working?
It's easy enough to have multiple microSD cards. I buy labels of two sizes and mark mine. So I can play with the Py2 rig to do a print, finish that, shut it down, swap in the microSD for the Py3 work and continue from there.
The Python 2 countdown clock says...
The reality is that we should start seeing a cascade of fail, basically. You might try to update a plugin on your Python 2.7 rig and one of its dependencies fires off and fails because that author no longer supports Py2 for, say, the RFID authentication stuff, for example. So the first line of fail is the dependencies which plugin authors here really can't control that well.
If you have more than one required third-party plugin then you might want to try camping out on Py2 for as long as you can stand the pain.
But if you're like me, you'll just wave off any non-compatible third-party OctoPrint plugins, setup for Py3 and drive on. I'll eventually get those back in if I truly need them in the future when they upgrade. Or perhaps I'll write my own if I need it that badly.
For me and all my 20+ plugins it wasn't too bad to go through the process, took a couple of weekends. Granted several of my plugins are UI related and the python change didn't make much of a difference. I did all mine in my windows dev environment, and then once I had worked through all the bugs related to my code and had full functionality created a separate py3 virtual environment on the pi and then just stop the octoprint service and manually start up the py3 version for testing.
I'm pretty sure the cookiecutter template for starting a new plugin has been updated, at least in the 1.4.0 Release Candidates.
Great work on this plugin. Works good for me. Really great to be able to rotate & zoom around.
I was wondering if it might be a possible option to turn the previously printed moves to a solid color (Grey, black, something) so that the layer that is printing is the only colored lines. Sometimes it is difficult to tell what has been printed and what is yet to be printed on the current layer.
Hi Paul, sorry for the late reply, I just saw this. Your idea sounds good and I'll give it a try once I can come back to this. It might be a bit since I need still need to update it for python 3.
Thanks, let me know when you get to it. There's only so much time in life, something's just take priority.
I took a look at what it would take to change the color of the current layer or previous layers while printing and it isn't as easy as I thought. To make it efficient to draw the huge number of lines needed I have to lock in the line color when I parse the gcode. I'll have to think on it. I might be able to do a trick with lighting or something.
I just got around to updating to OctoPrint 1.4 and I am somewhat surprised to see this plugin still works. I guess I misunderstood the Python 3 transition plan.
One issue I do see is the bed size or position now seems to be off. Is that just me?
Anyone else have any issues with this plugin after 1.4?
It appears right to me @Kragrathea, here's my 300 x 300 bed. Did you make sure your bed profile in settings matches your printer?
The full switch over to Python 3 probably won't happen for a year.
It looks like (for me) the bed size is wrong if I reload the page while on the Pretty Gcode Tab. It reports 200x200 instead of 300x300.
I just noticed this when I switched to full screen mode, which reloads the page with your tab active and it cuts off like you say. Even after exiting fullscreen mode. It looks like it renders the bed to the extents of the "printed objects" from the origin of 0,0. Notice it goes as far up as the purge line and as far right as the skirt. Not sure if that is exactly at 200x200 or not...
I load the bed volume in onTabChange via printerProfiles.currentProfileData. Perhaps that can happen too early for the currentProfile to be set.
var bedVolume = undefined;
var viewInitialized = false;
self.onTabChange = function (current, previous) {
if (current == "#tab_plugin_prettygcode") {
if (!viewInitialized) {
viewInitialized = true;
//get printer build volume.
//console.log(["self.printerProfiles",self.printerProfiles.currentProfileData()]);
var volume = self.printerProfiles.currentProfileData().volume;
if(typeof volume.custom_box ==="function")//check for custom bounds.
{
bedVolume={
width:volume.width(),
height:volume.height(),
depth:volume.depth(),
origin:volume.origin(),
formFactor:volume.formFactor(),
}
}else{
//console.log(["volume.custom_box",volume.custom_box]);
bedVolume={
width:volume.custom_box.x_max()-volume.custom_box.x_min(),
height:volume.custom_box.z_max()-volume.custom_box.z_min(),
depth:volume.custom_box.y_max()-volume.custom_box.y_min(),
origin:volume.origin(),
formFactor:volume.formFactor(),
}
}