This change should make sure that only those settings actually make it into config.yaml
per plugin that do differ from the default settings. Up until now the full dictionary as received
e.g. from the REST API was saved, regardless whether it contained (only) default values or not.
That led to a lot of "null" entries in the config.yaml file, which for one looked horrible and also
led to problems when a plugin actually wanted to change its default values.
With this commit, two things are done. One, upon saving a configuration the default
implementation of the save routine in the settings plugin now first diffs the new data against
the defaults and only saves what is different. Two, upon server startup a cleanup method is
now called on settings plugins whose default implementation fetches the current data stored
in config.yaml, diffs that against the defaults and only writes back the diff result. If that is empty
the entry is completely deleted from config.yaml.
(cherry picked from commit d70fe32)
That way plugins don't need to implement the SettingsPlugin mixin in order to access their data folder, which is now an injected property in OctoPrintPlugin. Plugin authors should still always use the getter since that will also make sure the folder actually does exist (lazy creation).
PluginSettings.get_plugin_data_folder has been marked as deprecated.
OctoPrint will take care of calling a migration function on the plugin if the plugin demands a newer configuration version than currently stored in config.yaml.
Added phase specific hooks for queuing, queued, sending and sent phases of a command ("octoprint.comm.protocol.gcode.<phase>"). Removed old queuing phase hook and declared as obsolete hook in plugin manager to prevent plugins that depend on it from being enabled.
Adding those new hooks also necessitated refactoring the whole command processing, made it more modular and added phase specific handler functions that allow handling all blocking commands centrally for example.
The new hook allows extending the list of rules for maximum body sizes differing from the default of 100KB and can be used by plugins to allow uploads to them that exceed that file size.
Also extended the plugin manager to detect plugins that implement restart needing hooks (such as the above one) and handling those plugins the same as plugins containing implementations that inherit from octoprint.plugin.core.RestartNeedingPlugin
Plugins may be enabled and disabled during runtime. If they are of types which allow hot loading, this will be done. Otherwise they will be marked as pending and updated after a restart. Same for installation and uninstallation.
Multiple mixins are allowed of course. Allowing multiple implementations lead to too many problems due to plugin names for referring to the APIs of SimpleApiPlugins or the assets of AssetPlugins.
Hence __plugin_implementations__ has been deprecated in favor of __plugin_implementation__. The plugin subsystem will automatically copy the first implementation from __plugin_implementations__ to __plugin_implementation__ and log a deprecation warning.
Adjusted documentation accordingly. Also added docs for helpers.
Detected plugins are now logged in a better readable way and with additional information.
Also marked folder for bundled plugins as bundled - forgot to do that earlier.
Preprocessing for better performancy, unit tests for preprocessing, controls don't need a type anymore (makes things way less complicated and repetitive)
Added wrappers to ensure existing plugins being able to work, although them using the old camel case method names now causes a deprecation warning being logged
Should catch any exceptions thrown by the plugin, log them and only hand them off if the caller requested to be informed about such things. This way if something goes wrong with a StartupPlugin there should be no problem anymore to still get the server up and running.
In order to solve the initial handshake problem with apps, OctoPrint now supports so called app session keys which are basically API keys with a limited validity. Obtaining those keys is based on a handshake procedure backed by RSA signatures. OctoPrint needs to be aware of apps and their associated public keys (with the AppPlugin there exists a mechanism to add additional recognized apps by installing a plugin). Apps perform the handshake by first requesting a temporary key with very limited validity, then sending a message back to OctoPrint containing their id, version, the temporary key and a signature created with their private key over these three pieces of data. OctoPrint then tries to verify the signature and if successful unlocks the key to be used as a fully recognized API key.
- File management is prepared to support folders (UI still lacking support)
- STL files are now first class citizens
- can be managed via the file list (and filtered from it)
- can be sliced on demand
- Slicing now happens via plugins
- Added Cura plugin
- uses CuraEngine directly instead of full Cura installation
- Cura profile importer for importing profiles from regular Cura installs via settings dialog
- TODO: UI for editing profiles
- API for slicing and slicing profile management
