mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #952] feat: plugin system — install, manage and convert OctoPrint plugins #658
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy#658
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Soopahfly on GitHub (Apr 12, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/952
Originally assigned to: @Soopahfly on GitHub.
Summary
I'd like to propose adding a first-class plugin system to Bambuddy. I've built a working implementation on my fork and would like to contribute it upstream.
Motivation
OctoPrint has a rich plugin ecosystem. Many users who migrate from OctoPrint to Bambuddy miss plugins like GCode visualisers, custom notifications, filament-change scripts, etc. A lightweight plugin system would let the community extend Bambuddy without requiring core changes for every feature.
What I've built
Plugin loader & base mixins
data/plugins/— auto-discovered on startupStartupPlugin,ShutdownPlugin,EventHandlerPlugin,SettingsPlugin,AssetPlugin,SimpleApiPluginPlugin API (
/api/v1/plugins).zip, detect type (Bambuddy native or OctoPrint), preview conversion, confirm install/{key}/assets/{path}) with path-traversal protectionSimpleApiPluginGET and command dispatchOctoPrint plugin converter
import octoprint,__plugin_pythoncompat__, class inheritanceStartupPlugin,SettingsPlugin,AssetPlugin,SimpleApiPlugin,EventHandlerPlugin1:1TemplatePlugin,BlueprintPlugin) with clear commentsFrontend
static/index.htmlBundled example: PrettyGCode
Includes a conversion of OctoPrint-PrettyGCode as a reference plugin:
layer_numvia MQTT (byte-offset map built by parsing the GCode file)Implementation notes
docker-compose.ymlgets a./plugins:/app/data/pluginsvolume mountPluginRecordDB table added via SQLAlchemy (existinginit_db()path)Questions for maintainers
data/plugins/location acceptable, or would you prefer a separatePLUGINS_DIRenv var?Happy to adjust the implementation based on feedback before submitting the PR.
@maziggy commented on GitHub (Apr 12, 2026):
Thanks for the detailed writeup @Soopahfly — it's clear you've put a lot of thought and work into this. Before we go further, I want to raise some concerns so we can discuss them:
Security surface — Auto-discovering and executing arbitrary Python packages from a directory, combined with a ZIP upload endpoint that installs code, is a significant trust boundary. Every plugin would run with full backend privileges (DB, filesystem, network). How are you thinking about sandboxing or permission scoping? Is there any isolation between plugins and core?
OctoPrint converter maintenance — The AST-based converter is clever, but OctoPrint's plugin API is large and evolving. Stubbing unsupported mixins (TemplatePlugin, BlueprintPlugin) means many real-world OctoPrint plugins won't convert cleanly. Have you tested this against a range of popular OctoPrint plugins beyond PrettyGCode? I'm concerned about the long-tail maintenance burden of keeping compatibility with an ecosystem we don't control.
Timing — Core features are still in active development (auth/SSO, queue automation, database migration). A plugin system is a foundational change that touches DB schema, Docker config, frontend routing, static asset serving, and the startup path. Every future change would need to account for it. I'd want to make sure the core is more settled before committing to this kind of architecture.
Scope — Would it make sense to break this into smaller pieces? For example, the G-code viewer looks genuinely useful as a standalone feature. And a simpler event-hook system (without the full plugin loader and OctoPrint converter) could be a less risky starting point if there's community demand.
Curious to hear your thoughts on these points.
@Soopahfly commented on GitHub (Apr 12, 2026):
Hey, thanks for taking the time to go through it properly.
On the security side — yeah, you're right, there's no sandboxing. Plugins run with full backend privileges. The upload
is admin-only and nothing loads until you explicitly enable and restart, but that's about it. Worth documenting
clearly but I'm not going to pretend it's more than it is.
On the OctoPrint converter — I think I'm going to drop that completely. Honestly it only half-worked even on my own
plugin, and maintaining compatibility with an ecosystem we don't control isn't worth it. If there's ever a use case
for it, a standalone offline tool makes more sense than baking it into the backend.
On timing — totally fair, you know the roadmap better than I do. Happy to keep the plugin loader on my fork and come
back to it when things are more settled.
The GCode viewer though — would that be worth a separate PR as a native built-in? No plugin system needed, just a
viewer page that hooks into the library and printer APIs you already have. That feels like the most useful bit anyway.
So I'll close this one out. Let me know if a focused GCode viewer issue is something you'd be open to.
@maziggy commented on GitHub (Apr 12, 2026):
Yes, definitely. Replacing the existing (bad) gcode viewer is already on my list. So you could just open a PR for it. That would be ver nice!
@Soopahfly commented on GitHub (Apr 12, 2026):
How does that look.
There's just an option on the left navbar for gcode viewer, and in there you can load a pre-sliced gcode file.
@Soopahfly commented on GitHub (Apr 12, 2026):
I realised it's loading the gcode viewer as a new tab instead of in the main pane. Just sorting that now.
@Soopahfly commented on GitHub (Apr 12, 2026):
Fixed that now.
@maziggy commented on GitHub (Apr 13, 2026):
Open a PR and I'll check more detailed. Thanks.