Skip to content

[FEATURE]: Virtual Environment Isolation #5

Description

@tedhabeck

🧭 Type of Feature

Please select the most appropriate category:

  • Enhancement to existing functionality
  • Developer tooling or test improvement

Virtual Environment Isolation

  • Design venv directory structure per plugin
  • Implement venv creation on plugin first load
  • Implement requirements.txt installation in venv
  • Execute plugin code within venv context
  • Cache venvs and detect requirements changes
  • Add configuration for venv base directory
  • Add cleanup for orphaned venvs

User Story 1

As a: plugin developer
I want: My plugin to run in an isolated virtual environment
So that: My plugin's dependencies don't conflict with other plugins

✅ Acceptance Criteria

Scenario: Plugin runs in isolated venv
  Given I have a plugin with dependency "transformers==4.35.0"
  And another plugin requires "transformers==4.30.0"
  When both plugins are loaded
  Then each plugin should have its own virtual environment
  And both plugins should function correctly with their respective versions

Scenario: Plugin venv is created automatically
  Given I register a new native Python plugin
  When the plugin is loaded for the first time
  Then a virtual environment should be created for the plugin
  And the plugin's requirements.txt should be installed
  And the venv location should be logged

Scenario: Plugin venv is reused on restart
  Given a plugin has an existing virtual environment
  When the gateway restarts
  Then the existing venv should be reused
  And dependencies should not be reinstalled unless changed

📐 Design Sketch (optional)

Include a diagram, sketch, or flow (use Mermaid if desired):



Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions