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.
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.
When any plugins are enabled/disabled, the client now gets a trigger to fetch a fresh list of update information from the server. This should take care of any old popups still hinting at now uninstalled plugins.
This is to make sure that they all end on a ; and hence stuff doesn't break if a file included directly after starts with a (...) construct. Of course it would be better if all bundled files are valid in that matter, however since we can't enforce that, we'll add this slight overhead to reduce the risk of stuff breaking.
See for example: http://stackoverflow.com/questions/20307462/js-cant-combine-lib-files
