Sadly, it didn't install. I can't find it in the plugin manager UI.
The process completed, or so it said, but nothing was installed. Installing from source might work if I knew how.
Neither of the two zip files — https://github.com/jneilliii/Octolapse/archive/refs/heads/master.zip and https://github.com/user-attachments/files/21278031/build_2025_06_19.zip — mentioned above worked properly. They installed but as plugin with no name which makes it hard to access. Not even sure I remember where in the UI OctoLapse is.
If I remember correctly it has it's own tab and a section in the settings.
someone else found a potential fix in discord. they were able to install with an additional pip argument. try adding --no-build-isolation to the pip configuration.
I'll take a look, thanks.
I don't see that screen…it just goes ahead with an install with predictable results. Where would I do that on the command line in the venv? Just add it to the existing command line?
python3 -m pip --disable-pip-version-check install . --no-cache-dir --no-build-isolation
[…]
Installing collected packages: Octolapse
Attempting uninstall: Octolapse
Found existing installation: Octolapse 0+unknown
Uninstalling Octolapse-0+unknown:
Successfully uninstalled Octolapse-0+unknown
Successfully installed Octolapse-0.4.5
Sounds great…where is it? 
I restarted OctoPrint, can't see it in the Plugin Manager.
I assume it would be in
./oprint/lib/python3.11/site-packages/octoprint/plugins
find . -type d -name octolapse
doesn't turn anything up.
UPDATE: at the very least, I am learning about pip and apt…
pip show Octolapse
Name: Octolapse
Version: 0.4.5
Summary: Create stabilized timelapses of your 3d prints. Highly customizable, loads of presets, lots of fun.
Home-page: https://github.com/FormerLurker/Octolapse
Author: Brad Hochgesang
Author-email: FormerLurker@pm.me
License: AGPLv3
Location: /home/paul/oprint/lib/python3.11/site-packages
Requires: awesome-slugify, file-read-backwards, OctoPrint, pillow, psutil, sarge, setuptools, six
Required-by:
That is what I would expect but it still doesn't show up in OctoPrint's UI. Not sure I made the right choice to upgrade since it required me to remove this.
We just received the same report, so I was digging a bit where this is coming from:
- It is not about
setuptools, but aboutsetuptools_octoprint, imported bysetup.pyof (older?) OctoPrint plugin templates:
Most, especially older plugins do not define setuptools_octoprint as explicit build dependency, so it makes sense that it is not available in the by default isolated build environment, hence the error. I found one newer plugin by @foosel herself which does define it as build dependency via pyproject.toml:
Maybe you can explain how it is/was intended to work? However, it really is the only one I found, browsing a dozen or so. Most newer ones do not make use of setuptools_octoprint, and all others which do, do not make use of pyproject.toml yet. So I assume that it is a changed behavior of newer setuptools which does not load build dependencies from the Python runtime site, but strictly sticks to the isolated site for build dependencies?
However, we install OctoPrint into a --user site, not into a venv. OctoPrint's pip call correctly detects this and uses the same flags, installing into the same site, so it looks correct, but probably the build dependency isolation works somehow differently in user vs venv sites. We aim to migrate everything into venvs anyway, but so far, I do not see yet how it would help in this case, since the error seems logic to me.
However, will do some tests.
--no-build-isolation actually might cause issues in the long term: It installs build dependencies not needed for runtime into the permanent runtime site. This can cause conflicts, modules might be downgraded by installing one plugin, breaking the other one. So if there is another solution, that would be highly preferred, not touching build dependency isolation. I'm testing OctoPrint-MfaTotp installation in our setup now, assuming it does not run into this error, since it declares setuptools_octoprint as build dependency.
I explained the reason for the issues in an faq item: OctoPrint can't install any plugins, says it "could not import OctoPrint's setuptools"
and also shipped 1.11.4 today which detects plugins that still rely on the old behaviour of non isolated installs (and thus octoprint_setuptools being available from octoprint itself) and installs them with the necessary pip arguments.
1.12.0 will also ship with a built in migration tool for plugin authors who want to fully migrate to pyproject.toml (I will look into also providing that in a standalone version earlier), and the plugin template has already been updated to that.
1 Like
Thanks, good to know I was no thinking into a totally wrong direction 
, but recent pip implies the breaking change instead of recent setuptools. Are there other possiblly missing build dependencies without --no-build-isolation? Otherwise, to keep its benefit/intentions intact, wouldn't it be better to just install octoprint_setuptools as regular runtime dependency with OctoPrint, where all plugins will find it in any case? It should happen the same way with --no-build-isolation, but that means that really all build dependencies end in the runtime site 
.
EDIT: Okay octoprint_setuptools is in the runtime site, but seems --no-build-isolation strictly requires all build dependencies in the isolated site then, and does not take any from the runtime site .
Yes, this is exactly how build isolation is supposed to work. And that's a change in how pip builds installable packages from source distributions.
When I initially created the plugin system I created these helpers in octoprint_setuptools to make it easier for plugin developers to get their plugin into an installable shape with various tooling for packaging and translating and such.
Back then, there was no such thing as build isolation. And I have to admit that I didn't have it on my radar that it would be forced on us this soon, an oversight on my part. I knew that it was coming, but for some reason I was rather thinking about 2026...
Long story short, for now OctoPrint will detect where build isolation won't work for installing or updating a package and tell pip accordingly. 1.12.0 will ship a tool that allows to port existing plugins easily from using octoprint_setuptools to a modern pyproject.toml setup with tooling provided in the shape of a task file, and I'll also look into porting this tool over into a standalone version tomorrow and push out a post about it. That will hopefully clear things up further.
1 Like
Great! And I now also see that octoprint itself "installs" the bundled octoprint_setuptools, but do now understand why it does not solve the issue, and why installing octoprint_setuptools explicitly as dedicated packages would not solve it either.
Despite that, I was just confused that I could not replicate the issue right now ... looks like I am some hours too late to the show, since OctoPrint 1.11.4 solved it already: Release 1.11.4 · OctoPrint/OctoPrint · GitHub
Anyway, learned some interesting Python background, and can tell our users that simply upgrading OctoPrint solves the issue 
.
Tool and guide now available here:
https://docs.octoprint.org/en/main/plugins/pyproject_toml_migration.html
Still trying to figure out how best to communicate this in a larger way.
@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__.pycommand_installdetects it as JSON and calls_command_install_jsonfileper entry calls againcommand_installdownloads and detects it as archive and calls_command_install_archivewhich callsis_pre_pep517_plugin_packageand in case addsPRE_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
and use
PluginManagerPlugin.command_install(url=plugin["archive"], name=plugin["id"])
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.
Thanks for the analysis (and clarification!)
I've just pushed this commit:
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!
1 Like
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
1 Like
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.
https://github.com/FormerLurker/Octolapse/archive/refs/tags/v0.4.5.zip