Plugin Tutorial Questions

Development
1

For the most part, the Plugin Tutorial is an excellent resource for someone starting out but I have a couple of questions that I couldn't find answers for.

However, since we are still working on our plugin, it makes more sense to use python setup.py develop for now – this way the plugin becomes discoverable by OctoPrint, however we don’t have to reinstall it after any changes we will still do.

I understand the "don't have to reinstall it" part but it isn't clear to me what steps to take after each code change. Do I python setup.py develop after each change or just restart OctoPrint?

I stumbled through the creation of the git repository and I probably could have done that better but it isn't clear from the tutorial how to transition from python setup.py develop to octoprint dev plugin:install and then transition to pip install https://github.com/yourGithubName/OctoPrint-HelloWorld/archive/master.zip. How should these transitions be done? When do I delete files in ~/devel?

Once the github repository is created and the plugin is submitted for approval. What are the recommended steps for making changes? Should I and if so, how would I return to using ~/devel for a more rapid debugging phase?

In addition to being new to writing a plugin for OctoPrint, I'm also a newbie git user and a novice Python programmer. Any additional pointers or suggestions on the lifecycle of an OctoPrint plugin are welcome.

2

Yes. And should you only be editing frontend stuff (.js, templates, stylesheets) even a reload should suffice.

Personally I just have my plugins in a source folder (equivalent to ~/devel) on my local development machine, develop against a local OctoPrint instance into which the plugins are installed via python setup.py devel, pip install -e . or octoprint dev plugin:install(which all do the same really) and from which I push to Github.

The zip installs for testing and later production from the repository/via the software update mechanism I do on the actual physical printer controllers or one of the Pis on the test cluster.

With regards to how to git, I'd recommend getting acquainted with the git command line and playing around a bit (in a separate local repository!) to get your bearings on how things work. Manually uploading individual files via the Github web interface is not what you should be aiming for, but rather learning how to create development branches, merging them back and pushing your changes to Github. Honestly way less of a hassle than the web interface as well once you have a bit of a rough idea.

I remember that this was a fairly good starting point:

https://rogerdudler.github.io/git-guide/

3

Not that it's necessarily the right way to do things, but this is my usual cycle:

  • I've created a folder somewhere on my MacBook using the cookiecutter technique as described in the plugin tutorial section
  • git init there in that folder
  • I use Visual Studio to edit the files
  • I have created a folder on the OctoPrint instance (Raspberry Pi 3B) which matches the repository name
  • I've created a bash script called syncit which looks like this (with some sanity checks):
rsync -avz ~/sites/OctoPrint-PluginName/ pi@octopi.local:~/OctoPrint-PluginName
  • I've added a macro in Visual Studio (Shift-Control-T) which will then run that script to sync the files over to the Raspi
  • I've added a bash script called on the Raspi itself which looks like:
#!/bin/sh

clear
cd ~/OctoPrint-PluginName
python setup.py develop
sudo service octoprint restart
tail -f ~/.octoprint/logs/octoprint.log

First boot of the day (remotely on the Raspi):

A. source oprint/bin/activate
B. cycle

So now, a cycle of work looks like:

  1. On my workstation, save one or more of the files within Visual Studio
  2. Press Shift-Control-T to sync the files over
  3. Task switch to the Terminal which has that Raspi session
  4. Ctl-C out of the existing activity (tail'ing the log)
  5. Up cursor to bring up the cycle command that I ran earlier and press Enter

The cycle script goes in /usr/local/bin so that it's in my search path. Note that macros in Visual Studio are stored at the project level, so you can have the same macro do different things for each.

At the end of a minor version, I'll edit the setup.py to add a fourth digit like 1.0.3.6, commit this and push it to two remote repositories. On major releases which work well enough to be noteworthy, it will get a version like 1.0.4. The commit will also get a tag and both code and tags are pushed in this case. (Just remember to sync to the Raspi after any of these events, too.) All of these activities happen in a second Terminal window.

Coding like this, you have to be sensitive to the location of your plugin. It won't be the same place as if someone later were to install it. So don't use paths in your code like /home/pi/OctoPrint-PluginName/pluginname/whatever...