Interesting that it's considered rather old since I seem to recall going through an update process a few weeks ago as well as a python upgrade I don't have a lot of confidence in. I realized during all this that it was still using the old version (3.9) when 3.11 was installed. I adjusted the symlink but the OctoLapse plugin still kicks out errors.
According to the UI, I have OctoPrint Version 1.11.3 which is listed as the current version on the download page. See also…
OctoPrint version : 1.11.3
OctoPi version : 1.0.0
cat /etc/octopi_version
1.0.0
I'd just as soon fix the errors as start over. Since the version numbers seem current, I should be close to a sane install…the parts are there, evidently, or those version numbers would not be. For an installation where octopi/print are the only things running, a virtual environment seems to add a layer of complication. Is there no way to just have a dedicated setup?
You are correct that the OctoPrint version is up to date. Your OctoPi (which is the customized Raspberry Pi OS) version is 1.0.0 and was flashed from an image created on October 9, 2023 (see below). The Python version in that OctoPi image was 3.9.2. Since you have Python 3.11.9 it has been updated since the image was originally flashed. If you have been doing apt update and apt upgrade as well, then the operating system and support files are also more up to date.
While fixing the errors is possible, it will be more work than "starting over" which will have the added advantage that you will also get a more up to date version of the operating system. OctoPi 1.0.0 is based on Debian 11 (bullseye). OctoPi 1.1.0 is based on Debian 12 (bookworm).
Running OctoPrint outside of a virtual environment is probably doable but you will be "on your own" for support as I believe all the people that frequently help out in this forum do not do so.
If you still want to attempt to fix your current system, then I'm afraid that is beyond my expertise level.
Well, there is a multi-day job running at the moment so I won't be doing anything to it at present. I may have run apt-update/upgrade at some point but I am not a Debian user so am not familiar with that.
I suppose there may be a manual that explains how to keep a system up to date without a complete re-flash? Not what I am used with other FOSS environments.
I'll see what can be done once this job is complete. I may have a spare SD card I can prepare in the event I have to start over from scratch.
so in the interest of completeness, here is some of what I have done to figure this out.
I created virtual environment in python3.11 and activated it, then tried installing the plugin through pip and by running the setup.py in its directory.
The one I created is called installer. I have tried using the one in octoprint but it didn't work. That may have been before I dealt with the errant symlink. The one in oprint was last accessed on 10/1/2025.
I think what I am looking for is how the venv can access the setup tools, to more clearly restate the original question. I have a hard time imagining this is impossible, either through outright copying them into place or using a symlink/path directive.
Your issue with installing OctoLapse is a known problem. You just need to copy/paste the release URL below into plugin manager > get more > ...from URL.
That worked, sort of. The installer has stalled after displaying this message:
Building wheel for Octolapse (setup.py): started
DEPRECATION: Building 'Octolapse' using the legacy setup.py bdist_wheel mechanism, which will be removed in a future version. pip 25.3 will enforce this behaviour change. A possible replacement is to use the standardized build interface by setting the `--use-pep517` option, (possibly combined with `--no-build-isolation`), or adding a `pyproject.toml` file to the source tree of 'Octolapse'. Discussion can be found at https://github.com/pypa/pip/issues/6334
I'll check back later today and see if it finishes. Perhaps making those changes will resolve it.
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 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?
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 about setuptools_octoprint, imported by setup.py of (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.
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.
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.
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 .
@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.
, but recent 
.
.