What does this mean? why would there be more than one python environment on a raspberry π device?
What did you already try to solve it?
Tried installing using pip, creating a venv, installing python from source, only to learn that I had done so but the symlink still pointed to the old version (3.9)
Have you tried running in safe mode?
no
Did running in safe mode solve the problem?
WRITE HERE
Systeminfo Bundle
You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
WRITE HERE
Additional information about your setup
OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible octoprint-systeminfo-20251018204632.zip (64.4 KB)
What I would like to see is a reliable way to install plugins. Either thru the UI/plugin manager or using pip. I don't know why I need a virtual environment when octoprint is the only process/application on this device. It's a raspberry π, not a laptop or general purpose desktop computer. I was going to install and run optolapse on a 44 hour job that would make a fun video but since the recent upgrade I can't reliably install plugins that are part of the octoprint's USP.
OctoPrint is a Python application and will run on any host that can run Python with the Raspberry Pi being one of those hosts. The laptop or the general purpose desktop you mention could potentially run OctoPrint. Many Python applications are designed to run in a virtual environment and this includes OctoPrint.
A properly configured OctoPrint has a reliable way to install plugins along with a very robust plugin library. This includes a reliable update system for both OctoPrint and its plugins.
The bundle you provided (Thank You!) shows that the OctoPi version is rather old (2023) and since the current installation has quite a few errors, my recommendation would be to start over on a new microSD card with the current version of OctoPi (stable). It looks like you only have two plugins (see below) so I don't believe you need to make a backup, but you can if you wish. Keeping the old microSD card will allow migrating any files you may have added that are not part of the actual OctoPrint environment.
| Third Party Plugins (2)
| Bed Visualizer (1.1.2) = /home/paul/oprint/lib/python3.11/site-packages/octoprint_bedlevelvisualizer
| Camera Settings (0.4.3) = /home/paul/oprint/lib/python3.11/site-packages/octoprint_CameraSettings
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 .
, but recent 
.
.