@foosel
While the workaround works with OctoPrint 1.11.4 when installing new plugins via plugin manager, and I see a commit which added the same for installs via CLI, it does not work yet with restoring a plugins JSON via plugin manager or when restoring an OctoPrint backup. The needed pip arguments are still missing in these cases, hence only a compatible subset of the previously installed plugins gets restored successfully.
I did not check through recent commits, so bare with me if you fixed that for a next release already. Will probably find time to open a commit later today.
Would be happy to get a PR if you have time for it!
I found an issue today caused by a tornado regression that I'll have to push out a release for, so fixing this problem as well could be done quite soon.
Let me know if such technical stuff should be better discussed on GitHub or elsewhere: I had a look at the related code:
Regarding plugins installed form JSON file, I am actually not sure why it does not work, since the very same code is called as when installing a single plugin, with the workaround done:
In plugins/pluginmanager/__init__.py
command_install detects it as JSON and calls
_command_install_jsonfile per entry calls again
command_install downloads and detects it as archive and calls
_command_install_archive which calls
is_pre_pep517_plugin_package and in case adds PRE_PEP517_PIP_ARGS
I'll add some debug code my end to hopefully find out why the arguments were still missing, while present when installing the same single plugin directly.
EDIT: It does work as expected, I seem to have checked falsely last time.
Regarding backup restore, it is a little more tricky, since the plugin is not first downloaded and extracted, but installed from URL directly, hence it cannot be checked whether it contains pyproject.toml or not, without duplicating a bunch of more code:
Probably it makes sense to
from octoprint.util.plugins import PRE_PEP517_PIP_ARGS, is_pre_pep517_plugin_package
or more complete
from octoprint.plugins.pluginmanager import PluginManagerPlugin
turning command_install into a @classmethod. But my Python knowledge and understanding of OctoPrint code is stretched a bit, e.g. I am not entirely sure of other impacts when importing PluginManagerPlugin as a whole, how to assure that the current GUI logging behavior is preserved, and what the partial argument does, just seeing that it affects some notification result type.
It is probably better and easier to consolidate things in some static install_plugin_from_uri method in octoprint.util.plugins, which builds the needed pip command, including PIP517 args, --user and what else the commands in PluginManagerPlugin do? So this one method can be used in the plugin manager, by the CLI, and when restoring backups? Installing from JSON could be also merged: from export and backup they are identical, aside of the archive key, which is missing in the JSON of the backup. But it uses the plugin manager repo info to get the archive URL based on plugin name, to finally do the same.
But this seems to be quite some restructure either way . The alternative hence to create more code duplication, download and extract the archive separately in backup restore code, and at least import and use the PEP517 check and args from octoprint.util.plugins.
I implemented a context manager that now takes care of downloading things if necessary, does the check and returns local path + required pip args, if anything, and utilized that where necessary.
Will go out with 1.11.5.
I was 100% sure I had implemented the plugin installation part of the restore utilizing the plugin manager and thus didn't test restore after implementing the fixes for 1.11.4, so a big thanks for the heads-up here about that!
Oh, and agreed on some refactoring being a good idea here in general, to consolidate the various duplicated code bits, however, that's something I'll rather do for 1.12.0 (which will get a proper RC phase) than in a bugfix release
Great, yeah that looks like just the right amount of what this new method does for now for a patch release, focusing on legacy plugins handling. I was thinking a bit too much in all or nothing manner. Seems a good start to unify further things in a future release, like Python environment detection => --user flag or not and such. But unless it fixes an actual bug, probably fine to do once there is some change needed anyway, which we know will coming as fast as pip and Python standards evolve .
Just upgraded to Version 1.11.5 and decided to check on OctoLapse. Still not able to install. Should it be in the plugin repository if it can't be installed? I don't know what else I could update to allow it to work…apt doesn't show any needs and OctoPrint is up to date. Is there a successor that anyone could recommend?
are you installing from the release URL? Go into plugin manager > get more button and at the bottom use the from URL field and copy/paste this into it and click install.
. The alternative hence to create more code duplication, download and extract the archive separately in backup restore code, and at least import and use the PEP517 check and args from