Plugin Manager now internally uses pkg_resources.parse_version and
pkg_resources.parse_requirements to check for version compatibility
with plugins from the repository. That will allow to directly use
the OctoPrint version string once it's PEP440 compatible.
Local file storage implementation will now "touch" added files to set
modification date to current date, ensuring that files that are just
moved through a custom implementation of file object (e.g. through the
watched folder mechanism) will show with "now" as the upload date.
If compatibility information is provided only as a version number it's
prefixed with >= for the check (so stating a compatibility of only
1.2.0 will now make the plugin compatible to all versions that follow
too).
Alternatively the compatibility information may now contain stuff like
">=1.2,<1.3" in which case the plugin will only be shown as compatible
to OctoPrint versions 1.2 and up but not 1.3 or anything above that.
Custom exception should be derived from Exception, not BaseException.
Not only is this specified in the python documentation, but also
tornado will be able to handle Exceptions in requests perfectly fine
and return an HTTP 500 for them, but crash hard (as in, server shut
down follows) for BaseExceptions.
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.
Doesn't work reliably across pip versions, and adding a special rule for each and every version also isn't fun. Plugin authors will need to use a different approach for pulling in dependencies that are not on pypi during install, e.g. extra install urls or something like that. For now, I give up here ;)
Will lookup the correct pip command to use if not provided as constructor parameter and determine the version. Implements __lt__, __le__, __gt__ and __ge__ for "less/greater than" checks against the pip version, for dynamicalle changing call parameters provided to the execute method based on availability.
Will allow adjusting software update and plugin manager plugins to only use --process-dependency-links for pip versions >= 1.5
Reduces number of requests done against (rate limited) github API, especially after consecutive server restarts. Forcing the update check still will query the API.
That's also able to cope with 0.3a and similar "non-semantic" version schemes. Semantic version comparison can still be forced by setting the compare_type in the check to "semantic". Strict equality check can be set similarly by using the value "unequal".
That's more user friendly than just blindly reloading the page. Also include installed Template- and AssetPlugins in the check whether there's a new version or not.
Caused by a wrong variable usage. Fixed the usage and added a migration
step that fixes the circular reference if it exists. Bumping configuration
version to 2.
Fixes#946
Introduced new callback for settings plugin to hook into the point after the settings have been migrated since the initialize method is not suitable for that as it might be called before other plugin implementations reachable through hooks are initialized.
Usage of super(MyClass, self) is henceforth discouraged due to dynamic reloading within OctoPrint's plugin subsystem. Refer to https://thingspython.wordpress.com/2010/09/27/another-super-wrinkle-raising-typeerror/ for details on this problem.
Action by plugin authors is needed to remove the super(...) call and substitute it with octoprint.plugin.SettingsPlugin.on_settings_save(self, data) and octoprint.plugin.SettingsPlugin.on_settings_load(self). Without these modifications, calls to plugin methods utilizing super(...) will fail after a call to the plugin managers reload_plugins method.
Closes#942
The SoftwareUpdate Plugin had a bug that caused way too much check data to be stored in the configuration, leading to plugins potentially being stuck in an "update available" loop although the update had already been applied. Now only the current version of github_commit update types is persisted, not the full check configuration.
Also introduced a configuration version and made the migration function migrate old configs to remove anything that was same as the default supplied for the "octoprint" and all plugin hook checks. That should clean things up in existing installations.
