In case the user site packages are not yet part of the used
working set OR the sys path and ENABLE_USER_SITE is true, the
manager will now make sure that the folder is searched for plugins
as well upon plugin reload.
This is necessary since Python will not automatically include the
user site directory upon firing up the program in case there's
nothing installed to it/it doesn't exist. If a plugin is installed
during run time with --user that will lead to it not being found,
which is undesirable. Hence run time manipulation of sys.path and
the workingset becomes necessary.
Managable currently pretty much only means "uninstallable".
Plugins are managable if their installation location is writable
and - if they are installed from an entry point and OctoPrint is
running in a virtual environment - within the bounds of the virtual
environment (because otherwise pip will not allow to uninstall).
There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
(cherry picked from commit 8af8b8f)
There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
