Add Plugin Manager

[v-murygin]

Plugin Manager

Adds a web-based Plugin Manager to install, update, and remove third-party plugins directly from
the InkyPi UI.

Summary

This PR introduces a full-featured plugin management system that enables users to:

• Install plugins from Git repositories or uploaded archives (ZIP/TAR)
• Update plugins automatically via git pull for git-based installations
• Remove plugins safely (builtin plugins are protected)
• View all installed plugins with repository info and update status

Changes

• Core Functions:
  • Git sparse checkout for efficient plugin installation
  • Automatic requirements.txt installation after install/update
  • Validation of plugin-info.json structure
  • Real-time plugin registry reload

UI Enhancements

• Main page: Added "Plugin Manager" button to plugins-controls section
• Plugin Manager page (plugin_manager.html)

Safety Features

• Builtin plugins cannot be updated or removed
• Only plugins with repository field in plugin-info.json can be updated
• Git-based detection via .git folder presence
• Pre-update commit hash comparison (shows "already up-to-date" if no changes)

Usage

Install from Git Repository:

1. Navigate to Plugin Manager
2. Select "Git Repository" tab
3. Enter plugin ID (must match folder name in repo)
4. Enter repository URL
5. Click "Install Plugin"

Update an Installed Plugin:

• Click "Update" button next to git-based plugins
• System will pull latest changes and reinstall dependencies

Remove a Plugin:

• Click "Remove" button (only available for third-party plugins)

Technical Details

Git Installation Flow:

1. Clone with --sparse and --filter=blob:none for efficiency
2. Sparse-checkout only the plugin folder
3. Move plugin files to plugins directory
4. Validate plugin-info.json structure
5. Install requirements.txt if present
6. Reload plugin registry

Update Detection:

• Compares commit hash before/after git pull
• Returns "already up-to-date" if no new commits
• Revalidates plugin structure and reinstalls dependencies

Archive Installation:

• Supports .zip, .tar.gz, .tgz, .tar
• Searches extracted files for plugin-info.json
• Same validation and dependency installation as git

📸 UI Screenshots

[v-murygin]

@fatihak I know there's already a https://github.com/RobinWts/InkyPi-Plugin-PluginManager out there 😄 , but
here's why I chose to integrate this directly into the core:

This feature is implemented as a core Flask blueprint rather than an external management tool for
several architectural reasons:

1. Plugin Lifecycle Access: Direct access to plugin_registry, validation pipeline, and
   load_plugins() enables immediate plugin availability without service restarts. External tools can
   only manage files, not runtime state.
2. Unified Interface: All device management (Settings, Playlists, API Keys, Plugins) lives in one
   authenticated web UI with consistent styling and access control.
3. Dependency Management: After updates, new requirements.txt entries are automatically installed
   into the active venv within the same request cycle—no manual intervention required.
4. State Consistency: Plugin Manager shares state with playlists, button configs, and plugin
   instances. Core integration enables real-time updates across all UI components.
5. Security: Git operations and dependency installation happen in a controlled Flask environment
   with existing authentication and error handling.

When external tools work better: Sandboxed plugin systems or multi-device orchestration. For
InkyPi's single-device, web-first architecture with tightly coupled plugins, core integration is
the natural fit.

[RobinWts]

For info: I chose plugin after core implementation was rejected.... #576

[v-murygin]

For info: I chose plugin after core implementation was rejected.... #576

@RobinWts Oh - I didn’t notice that earlier thread.... It actually looks like this is a pretty common request, and people keep coming back to the idea of a built-in plugin manager.
The core integration approach makes a lot of sense for the current architecture and usage model. Maybe once it’s clear how useful and stable this solution is in practice, there’ll be more willingness to eventually bring it into the main project 🙂

[RobinWts]

Well at first I thought the same and used a new blueprint along the other core blueprints but after transforming the pluginmanager to a plug-in and creating the core patch that adds a generic blueprint registration for plugins I believe that‘s not a bad thing. I might create a PR to integrate the patch in the core, that way plugins generally could do „other stuff“ and are not limited to just creating display outputs… On the other hand there are valid concerns about plugins being able to create their own routes and so on.