New release: 1.4.1

Blog
1

Fresh off the presses, just through a month long release candidate cycle and the first one to be developed during a raging pandemic - which as I want to add turned out to be quite the challenge thanks to a ridiculously increased support overhead 😱 - I present you the next stable release of OctoPrint: 1.4.1! 🥳

Like every single release (and release candidate) of OctoPrint ever since early 2016 this was made possible only through your continued support of my work 💕

The full changelog contains a long list of improvements and bug fixes, but here are some of the highlights:

  • The temperature tab got a new control to select preconfigured temperature profiles on all heaters with one click
  • The newly bundled “File Check” plugin will sanity check uploaded files and warn about potential issues. Currently the plugin only detects {travel_speed} place holders left in GCODE. Read more in the plugin’s README.
  • The first run wizard now allows to restore from a plugin right away.
  • You can now move files in the file list to other folders without the need of a third party plugin.
  • The Plugin Manager now shows stats on the plugins available on the repository, such as number of known installs, date of last release etc. Installed plugins now also make it more transparent whether they are already compatible to Python 3 or not.
  • The Plugin Manager now also supports installing so called single-file plugins - mini plugins only consisting of a single python file which are a quick and easy way to work around broken communication or similar backend-only situations. This feature was developed live on air, you can learn more about it in this episode of OctoPrint Code & Chat. Consequently, the Software Update plugin was also extended with some new version check and updater types to support auto-updating single file plugins, read more in the docs here.
  • The Printer Safety Check has been renamed to Firmware Check & extracted into a still bundled but separately maintained plugin. It now also detects firmware with known broken communication protocol implementations (like the infamous CBD make it and ZWLF make it variants) and links to related FAQ entries on detection.
  • The broken by design comm port auto detection has been rewritten completely from scratch. That should hopefully make auto detection work more reliably in the future.
  • Original file modification timestamps will now be persisted on restoring from a backup.
  • The “read-only” group behaviour has been fixed so that it is actually possible to create a read-only account. The User group is no longer enforced on users, though pre checked for new users (if kept default). This makes it also possible to create group less users, so keep that in mind.
  • The permission issue that kept the Announcement icon from showing up on the navbar has been solved.
  • A bunch of dependencies were upgraded to the latest versions. Among these are also the web server framework Flask, the templating engine Jinja2 and something that pulls in a conflicting slugify library, which resulted in a bunch of heads-ups for users and plugin authors, read below.
  • … and many more improvements & fixes.

There are also a bunch of heads-ups with this release.

Heads-ups

Please read the following carefully, it might impact you and how you use OctoPrint! Also see the Further Information and Links below for more information, where to find help and how to roll back.

Heads-up for users of the Telegram plugin v1.5.0 or lower (and possibly other plugins that use long deprecated flask.ext imports)

The Telegram plugin up until the currently latest version 1.5.0 from August 7th 2019 is incompatible to OctoPrint 1.4.1 and later (see this ticket). The reason for that is that OctoPrint had to update its third party Flask dependency for security reasons, and this plugin (and possibly others) still use an import syntax related to that dependency that has been deprecated and warned about for several years now and which finally has been removed in current versions of Flask.

A fix has been provided to the Telegram plugin maintainers and has been merged, but so far no new release has been pushed out.

If you notice the Telegram plugin or another third party plugin no longer loading under OctoPrint 1.4.1 with an error logged to octoprint.log that looks similar to

  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/core.py", line 972, in _import_plugin
    module = _load_module(module_name, spec)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/core.py", line 71, in _load_module
    return imp.load_module(name, f, filename, details)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_telegram/__init__.py", line 5, in <module>
    from flask.ext.babel import gettext
ImportError: No module named ext.babel

then this outdated import syntax is the reason. That is something that needs to be fixed by the plugin maintainers by pushing out a new release. Please do not open issues about this on the OctoPrint repository, I cannot do anything about this.

Heads-up for plugin authors: Jinja2 update has one backwards incompatibility, please read

Current Jinja versions no longer allow modifying variables set outside of for loops inside them. See also #1697 and the Jinja docs here.

The Jinja dependency upgrade thus introduces a breaking change for plugins as well. However, it was necessary for security reasons: older versions have a bug that could allow template authors to break out of the template sandbox. Not a huge risk in the context of OctoPrint (plugins already have a lot more power than jinja would give them), but still overdue to fix.

You can find more details and example code in the Release Notes.

Heads-up for plugin authors: awesome-slugify is now bundled as octoprint.vendor.awesome_slugify, update your imports!

Due to a necessary dependency update of a third party dependency pulling in a different slugify library (“python-slugify”) that clashes with awesome-slugify, the latter has been bundled. If you use import slugify anywhere in your code, please be aware that that will now possibly pull in the aforementioned other library or possibly a partially overwritten awesome-slugify. Plugin authors are advised to update the imports of awesome-slugify like this:

### old
# example 1
import slugify
# example 2
from slugify import Slugify
### new
# example 1
try:
  # OctoPrint>=1.4.1
  import octoprint.vendor.awesome_slugify as slugify 
except ImportError:
  # OctoPrint<=1.4.0
  import slugify
# example 2
try:
  # OctoPrint>=1.4.1
  from octoprint.vendor.awesome_slugify import Slugify
except ImportError:
  # OctoPrint<=1.4.0
  from slugify import Slugify

That will also guarantee backwards compatibility if installed under OctoPrint versions prior to 1.4.1. Alternatively switch fully to the 1.4.1 version and adjust your plugin listing to a minimum OctoPrint version of 1.4.1.

Heads-up for developers: The included virtual printer has had its settings migrated to a different location in config.yaml

The bundled Virtual Printer plugin has finally been turned fully isolated into a self contained plugin and thus its settings have been moved from devel.virtualPrinter to plugins.virtual_printer in config.yaml. An auto migration is in place that should take care of moving anything already configured on first start under 1.4.1+, however should you be somehow manipulating config.yaml through automation or something in order to change virtual printer settings, you’ll have to update your workflows.

Thanks

Special thanks to everyone who contributed to this release and provided full, analyzable bug reports and pull requests, especially @drifkind, @eyal0, @FedericoNembrini, @fieldOfView, @flaviut, @jneilliii, @joshfriend, @justfalter, @kerber, @lachyc, @osubuu and @tedder for their PRs!

And last but not least, another special Thank you! to everyone who reported back on the release candidates this time: @b-morgan, @ChrisHeerschap, @cp2004, @ctgreybeard, @dcodom, @DodgeDeBoulet, @gege2b, @gmccauley, @hamster65, @jbjones27, @jneilliii, @JohnOCFII, @kantlivelong, @louispires, @marknn3, @NotExpectedYet, @ogsv, @schnello, @spling-du-futur and @zeroflow.

Insights

If you are interested in some numbers, here’s some data extracted from the anonymous usage tracking for the four RCs that went before 1.4.1’s stable release:

  • 1.4.1rc1 (2020-07-06): 269 instances, 1865h or 2.6 months of accumulative printing time
  • 1.4.1rc2 (2020-07-08): 480 instances, 7790h or 10.8 months of accumulative printing time
  • 1.4.1rc3 (2020-07-15): 679 instances, 15500h or 1.8 years of accumulative printing time
  • 1.4.1rc4 (2020-07-29): 454 instances, 4400h or 6 months of accumulative printing time

And if you haven’t yet, maybe also check out this recent post on the new test rig I built for the final update tests I do for each and every OctoPrint release and release candidate.

Further Information

It may take up to 24h for your update notification to pop up, so don’t be alarmed if it doesn’t show up immediately after reading this. You can force the update however via Settings > Software Update > Advanced options > Force check for update.

If you get an error about “no suitable distribution” during update, please read this.

If you have any problems with your OctoPrint installation, please seek support on the community forum.

Links

This is a companion discussion topic for the original entry at https://octoprint.org/blog/2020/08/04/new-release-1.4.1/
3 Likes