If we set method to pip in 1.3.6 and then roll back to 1.3.5 we will
need to a manual config.yaml update otherwise or we will no longer be
able to update.
Be removing the force parameter and using the actual default settings
instead of current ones, we don't do that anymore.
Make sure to set the actual effective offsets as provided by the comm
layer (which merges incoming single offset adjustments) instead of only
setting the input, effectively nuking return of offsets set prior.
Closes#2268
Didn't match Marlin's "checksum mismatch", only Repetier's "checksum
error". Since the error handler checks against
recoverable_communication_errors before
resend_request_communication_errors, we can just switch back to the more
broader check against "checksum" for the latter.
We could also have added an explicit check for "checksum mismatch"
instead but since we used to check for "checksum" and we don't know what
other varieties for this specific error might be out there in the
thousands of firmware variants (who needs consistency when they can
have a free for all?), we'll err on the side of caution instead.
Fixes#2262
It's no longer reliable since the Github archive export we'll now
usually use for upgrading does weird things when a tag is available on
more than one branch and we don't want our current stable version to
be reported as "rc/devel" just because that tag is available there too.
A full blown version number should be definitive enough considering that
if it's not a tag it will also contain the commit hash.
We don't need to define them in the firmware AND in OctoPrint. If they
are already set in firmware we'll otherwise get wonky issues in the
GCODE viewer or when slicing.
Closes#2229
As discussed in #2200.
For this to work we've introduced sub-bundles per plugin for the JS
assets. CSS and LESS on the other hand are basically handled as before.
We use a custom bundle class here since it's apparently not possible to
keep a sub bundle from inheriting the parent's filters, thus not
allowing us something like
packed_plugins [js_plugin_delimiter_bundler]
packed_plugin_a [js_delimiter_bundler]
packed_plugin_b [js_delimiter_bundler]
...
The individiual bundles per plugin would inherit
js_plugin_delimiter_bundler and we'd get a double wrapper - not helpful.
Instead we now have a modified JsPluginBundle that overwrites
Bundle._merge_and_apply to further wrap the returned hunk.
Since we only ever handle one requirement here, the parse_requirements
generator (which btw needs a next m() is not the best choice.
Also extracted install command cleanup into class method and added tests
for that.
cc @markwal
No guarantees however that transporting anything BUT gcode via the usual
M28/M29 interface will even remotely work. Note that it most likely
won't work if the transferred file contains an M29 (= end transfer),
just like with transferred GCODE files.
Also note that stuff like config files or some such that might be
transferred might contain lines that are too large to fit into the
buffer of the printer. This is really just to enable plugins to maybe do
some nifty stuff, no official support of streaming arbitrary files to
the printer's SD (for that we'd need WAY more firmware support first).
See jneilliii/OctoPrint-SmoothiewareConfig#1
