[Feature Request]: 能否将扩展插件安装在其单独的虚拟环境里？Can the extension be installed in its own virtual environment?

[love530love]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

在扩展管理器中增加功能：让每个扩展插件单独使用该插件的虚拟环境，避免依赖冲突，并且与主项目环境依赖相隔离。 Add functionality to the extension manager to make each extension use its own virtual environment, avoiding dependency conflicts and isolating it from the main project environment dependencies.

Proposed workflow

如果插件是从主项目的Web端搜索和安装的，那么这些插件的安装和运行环境可能会受到主项目环境的影响。在这种情况下，要实现每个插件都有自己的独立虚拟环境，需要主项目Web端支持这样的操作。这通常涉及到以下几个方面：

Indeed, if plugins are searched for and installed from the main project's web interface, their installation and runtime environment may be influenced by the main project's environment. In this case, to implement an independent virtual environment for each plugin, the main project's web interface needs to support such operations. This usually involves the following aspects:

1. 插件管理器的集成：主项目的Web端需要有一个插件管理器，它能够识别和处理每个插件的独立环境需求。这意味着插件管理器需要能够为每个插件创建、管理和激活其独立的虚拟环境。

   1. Integration of Plugin Manager: The main project's web interface requires a plugin manager that can recognize and handle the independent environment needs of each plugin. This means the plugin manager needs to be able to create, manage, and activate an independent virtual environment for each plugin.

2. 环境隔离：主项目需要能够确保插件在激活其独立虚拟环境时，不会干扰到主项目或其他插件的运行。这可能需要在Web端进行一些配置，以便在安装和运行插件时，能够切换到正确的虚拟环境。

   2. Environment Isolation: The main project needs to ensure that when plugins activate their independent virtual environments, they do not interfere with the operation of the main project or other plugins. This may require some configuration on the web interface to switch to the correct virtual environment when installing and running plugins.

3. 依赖解析和安装：当用户通过Web端安装新插件时，主项目需要能够解析插件的依赖，并在插件的独立虚拟环境中安装这些依赖。这可能需要插件提供明确的依赖列表，并且主项目有能力在虚拟环境中处理这些依赖。

   3. Dependency Resolution and Installation: When users install new plugins through the web interface, the main project needs to be able to resolve the plugin's dependencies and install them in the plugin's independent virtual environment. This may require the plugin to provide a clear list of dependencies, and the main project must have the capability to handle these dependencies within the virtual environment.

4. 用户交互：用户界面需要提供清晰的指示，告知用户插件是如何在独立环境中运行的，以及如何在需要时切换或管理这些环境。

   4. User Interaction: The user interface needs to provide clear instructions on how plugins run in an independent environment and how to switch or manage these environments when needed.

如果主项目的Web端不支持这样的操作，那么实现每个插件都有自己的虚拟环境可能会比较困难。在这种情况下，可能需要考虑其他的解决方案，比如使用容器化技术（如Docker）来为每个插件创建独立的运行环境，或者在主项目中实现更高级的依赖冲突解决机制。

If the main project's web interface does not support such operations, it may be difficult to implement an independent virtual environment for each plugin. In this case, other solutions may need to be considered, such as using containerization technology (such as Docker) to create an independent runtime environment for each plugin, or implementing more advanced dependency conflict resolution mechanisms within the main project.

为了实现Stable diffusion web UI中的插件独立于主项目运行在各自的虚拟环境中，可以在插件管理器中采取以下步骤。这里我们将使用Python的virtualenv工具来创建和管理这些虚拟环境。

To implement the plugins in Stable diffusion web UI to run independently from the main project in their respective virtual environments, the following steps can be taken in the plugin manager. Here, we will use Python's virtualenv tool to create and manage these virtual environments.

安装 virtualenv（如果你尚未安装）：

Install virtualenv (if you have not installed it yet):

pip install virtualenv

为每个插件创建一个独立的虚拟环境。例如，对于名为plugin1的插件，执行：

Create an independent virtual environment for each plugin. For example, for a plugin named plugin1, execute:

virtualenv plugin1_venv

对于plugin2执行类似操作，并将plugin1_venv替换为plugin2_venv。

Perform a similar operation for plugin2, replacing plugin1_venv with plugin2_venv.

激活相应的虚拟环境并安装插件所需的依赖。例如，激活plugin1_venv：

Activate the corresponding virtual environment and install the dependencies required by the plugin. For example, to activate plugin1_venv:

source plugin1_venv/bin/activate

然后，在激活的虚拟环境中安装插件的依赖：

Then, install the dependencies of the plugin in the activated virtual environment:

pip install -r plugin1/requirements.txt

对于plugin2执行类似操作，并将plugin1替换为plugin2。

Perform a similar operation for plugin2, replacing plugin1 with plugin2.

在主项目中，确保正确导入插件。由于我们有多个虚拟环境，我们需要一种方式来在运行时切换到正确的虚拟环境。这可以通过编写一个函数来完成，该函数根据插件名称加载相应的虚拟环境并执行插件代码。下面是一个简单的示例：

In the main project, ensure that the plugins are correctly imported. Since we have multiple virtual environments, we need a way to switch to the correct virtual environment at runtime. This can be accomplished by writing a function that loads the corresponding virtual environment based on the plugin name and executes the plugin code. Here is a simple example:

import os
import sys

def run_plugin(plugin_name):
    # 获取插件名对应的虚拟环境路径
    venv_path = f"{os.path.dirname(__file__)}/plugins/{plugin_name}/{plugin_name}_venv"

    # 将虚拟环境的bin目录添加到系统路径中
    activate_this = os.path.join(venv_path, "bin", "activate_this.py")
    with open(activate_this) as file:
        code = compile(file.read(), activate_this, 'exec')
        exec(code, dict(__file__=activate_this))

    # 导入并运行插件模块
    import plugin1_module  # 假设插件模块名为plugin1_module
    plugin1_module.run()

# 使用插件
run_plugin("plugin1")  # 调用插件1
run_plugin("plugin2")  # 调用插件2

在这个例子中，我们首先获取插件名称对应的虚拟环境路径，然后通过读取并执行activate_this.py文件来激活虚拟环境。接着，我们可以像平常一样导入并运行插件中的模块。

In this example, we first obtain the path to the virtual environment corresponding to the plugin name, then activate the virtual environment by reading and executing the activate_this.py file. Next, we can import and run the modules in the plugin as usual.

这种方法允许你在主项目中使用不同版本的库，而不会干扰其他插件或主项目本身的依赖关系。每次运行插件时，都会临时激活对应的虚拟环境，执行完后再返回到原来的全局环境。

This method allows you to use different versions of libraries in the main project without interfering with the dependencies of other plugins or the main project itself. Each time a plugin is run, the corresponding virtual environment is temporarily activated and then returned to the original global environment after execution.

注意：这个方法假设你的插件结构是这样的：

Note: This method assumes your plugin structure is as follows:

project_root/
|-- main.py
|-- plugins/
|   |-- plugin1/
|   |   |-- requirements.txt
|   |   |-- plugin1_module.py
|   |-- plugin2/
|   |   |-- requirements.txt
|   |   |-- plugin2_module.py
|-- ...

在这个结构中，每个插件有自己的requirements.txt文件和相关模块。

In this structure, each plugin has its own requirements.txt file and associated modules.

Additional information

This feature proposal comes from此功能建议方案来自于CSNDhttps://ask.csdn.net/questions/8089444?answer=54605981&username=u014451778&utm_medium=notify.im.haveAnswer.20240416.a @专家-赤兔[在线]

[wfjsw]

While the concept looks helpful, the way you proposed will only work under a harsh requirement, where any extension must not share any part of the dependency tree with others. This is practically impossible. Otherwise, you risk messing up the entire cached module tree with duplicated yet conflicting dependency versions, and you cannot really tell what version of the library you are importing.

[love530love]

Thank you for your reply! My main goal is to completely solve the problem that the dependencies of many plugins will conflict with the dependencies of the main project. Do you have any good solutions? Different plugins require different versions of the main project such as Pytorch, onnxruntime, XFormers, and so on. Reinstalling plugins based on their dependencies causes the project to break. 感谢您的回复！我主要的目的是想彻底解决众多插件的依赖会与主项目的依赖相冲突的问题，请问你有没有什么好的解决方案呢？不同插件对主项目比如对Pytorch、onnxruntime、XFormers库版本要求不同，根据插件依赖要求重新安装造成项目瘫痪的问题

[wfjsw]

There is not much you can do with these ones containing C extensions.

[jim60105]

Each torch package requires 3.6G of disk space, so you will need 10G for three extensions that require torch.😉

The good solution is that all the extension MUST align its dependencies with the main project.

[love530love]

对于这些包含 C 扩展的文件，您无能为力。对于这些包含 C 扩展的代码，您可以做的事情很少。

感谢指导！那我就不纠结了

[love530love]

每个torch包需要3.6G的磁盘空间，因此三个需要torch的扩展需要10G。😉

好的解决方案是所有扩展都必须使其依赖项与主项目保持一致。

这个方案好是好，只是从web端直接搜索安装会比较方便可是也会在web端安装扩展的依赖时导致主项目崩溃，然后就要重新调试。您的意思是不是：直接下载想要的扩展的源代码包，然后修改requirements.txt文件之后，再从本地安装呢？望不吝赐教，谢谢!

[jim60105]

每个torch包需要3.6G的磁盘空间，因此三个需要torch的扩展需要10G。😉 好的解决方案是所有扩展都必须使其依赖项与主项目保持一致。

这个方案好是好，只是从web端直接搜索安装会比较方便可是也会在web端安装扩展的依赖时导致主项目崩溃，然后就要重新调试。您的意思是不是：直接下载想要的扩展的源代码包，然后修改requirements.txt文件之后，再从本地安装呢？望不吝赐教，谢谢!

The maintainer of the extension SHOULD maintain its consistency. Of course, you can open an issue or a PR to fix it. This is how we play in open source.