langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Model provider configure occur 'no available node, plugin not found' error. #8882

New Issue
Closed
opened 2026-02-21 18:28:22 -05:00 by yindo · 15 comments
yindo commented 2026-02-21 18:28:22 -05:00
Owner
Copy Link
Copy Source

Originally created by @raye-deng on GitHub (Mar 2, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.0.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Steps to reproduce:

  • open model providers setting
  • configure open AI (or any other model providers) key
  • error message popup 'Internal server error'
  • backend service log show: 'no available node, plugin not found'

following is the error logs :

2025-03-03 03:56:41,978.978 ERROR [Dummy-21] [app.py:875] - Exception on /console/api/workspaces/current/model-providers/langgenius/openai/openai [POST]
Traceback (most recent call last):
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 489, in wrapper
    resp = resource(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/views.py", line 110, in view
    return current_app.ensure_sync(self.dispatch_request)(**kwargs)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 604, in dispatch_request
    resp = meth(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 147, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/libs/login.py", line 94, in decorated_view
    return current_app.ensure_sync(func)(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/wraps.py", line 27, in decorated
    return view(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/controllers/console/workspace/model_providers.py", line 102, in post
    model_provider_service.save_provider_credentials(
  File "/app/api/services/model_provider_service.py", line 145, in save_provider_credentials
    provider_configuration.add_or_update_custom_credentials(credentials)
  File "/app/api/core/entities/provider_configuration.py", line 244, in add_or_update_custom_credentials
    provider_record, credentials = self.custom_credentials_validate(credentials)
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/entities/provider_configuration.py", line 227, in custom_credentials_validate
    credentials = model_provider_factory.provider_credentials_validate(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_runtime/model_providers/model_provider_factory.py", line 150, in provider_credentials_validate
    self.plugin_model_manager.validate_provider_credentials(
  File "/app/api/core/plugin/manager/model.py", line 97, in validate_provider_credentials
    for resp in response:
                ^^^^^^^^
  File "/app/api/core/plugin/manager/base.py", line 189, in _request_with_plugin_daemon_response_stream
    self._handle_plugin_daemon_error(error.error_type, error.message)
  File "/app/api/core/plugin/manager/base.py", line 223, in _handle_plugin_daemon_error
    raise PluginDaemonInternalServerError(description=message)
core.plugin.manager.exc.PluginDaemonInternalServerError: PluginDaemonInternalServerError: no available node, plugin not found
Image

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Originally created by @raye-deng on GitHub (Mar 2, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.0.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Steps to reproduce: - open model providers setting - configure open AI (or any other model providers) key - error message popup 'Internal server error' - backend service log show: 'no available node, plugin not found' following is the error logs : ``` 2025-03-03 03:56:41,978.978 ERROR [Dummy-21] [app.py:875] - Exception on /console/api/workspaces/current/model-providers/langgenius/openai/openai [POST] Traceback (most recent call last): File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 917, in full_dispatch_request rv = self.dispatch_request() ^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask/app.py", line 902, in dispatch_request return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 489, in wrapper resp = resource(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask/views.py", line 110, in view return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 604, in dispatch_request resp = meth(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/app/api/controllers/console/wraps.py", line 147, in decorated return view(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/app/api/libs/login.py", line 94, in decorated_view return current_app.ensure_sync(func)(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/controllers/console/wraps.py", line 27, in decorated return view(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/app/api/controllers/console/workspace/model_providers.py", line 102, in post model_provider_service.save_provider_credentials( File "/app/api/services/model_provider_service.py", line 145, in save_provider_credentials provider_configuration.add_or_update_custom_credentials(credentials) File "/app/api/core/entities/provider_configuration.py", line 244, in add_or_update_custom_credentials provider_record, credentials = self.custom_credentials_validate(credentials) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/entities/provider_configuration.py", line 227, in custom_credentials_validate credentials = model_provider_factory.provider_credentials_validate( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_runtime/model_providers/model_provider_factory.py", line 150, in provider_credentials_validate self.plugin_model_manager.validate_provider_credentials( File "/app/api/core/plugin/manager/model.py", line 97, in validate_provider_credentials for resp in response: ^^^^^^^^ File "/app/api/core/plugin/manager/base.py", line 189, in _request_with_plugin_daemon_response_stream self._handle_plugin_daemon_error(error.error_type, error.message) File "/app/api/core/plugin/manager/base.py", line 223, in _handle_plugin_daemon_error raise PluginDaemonInternalServerError(description=message) core.plugin.manager.exc.PluginDaemonInternalServerError: PluginDaemonInternalServerError: no available node, plugin not found ``` <img width="555" alt="Image" src="https://github.com/user-attachments/assets/9d3525ed-85f1-4e14-ad7e-c26d1bfea554" /> ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 18:28:22 -05:00
yindo closed this issue 2026-02-21 18:28:22 -05:00
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Mar 2, 2025):

Hello @raye-deng! I'm here to help you with any bugs, questions, or contributions you have. Let's work together to solve the issue you're facing.

To resolve the "no available node, plugin not found" error when configuring the model provider in a self-hosted Dify version 1.0.0 setup, you can try downgrading the dify-api and dify-web services to version 0.15.3 in your docker-compose.yaml file. This workaround addresses the database connection issue in the plugin_daemon component in v1.0.0-beta, which causes the error [1].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Mar 2, 2025): <!-- Greeting --> Hello @raye-deng! I'm here to help you with any bugs, questions, or contributions you have. Let's work together to solve the issue you're facing. <!-- Answer --> To resolve the "no available node, plugin not found" error when configuring the model provider in a self-hosted Dify version 1.0.0 setup, you can try downgrading the `dify-api` and `dify-web` services to version 0.15.3 in your `docker-compose.yaml` file. This workaround addresses the database connection issue in the `plugin_daemon` component in v1.0.0-beta, which causes the error <sup>[[1]](https://github.com/langgenius/dify/issues/13777)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=other)</sup>
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@raye-deng commented on GitHub (Mar 3, 2025):

Hello @raye-deng! I'm here to help you with any bugs, questions, or contributions you have. Let's work together to solve the issue you're facing.

To resolve the "no available node, plugin not found" error when configuring the model provider in a self-hosted Dify version 1.0.0 setup, you can try downgrading the dify-api and dify-web services to version 0.15.3 in your docker-compose.yaml file. This workaround addresses the database connection issue in the plugin_daemon component in v1.0.0-beta, which causes the error [1].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

I think this is not the same issue. Apart from the failure of the configured model, other already configured models also report errors when opened, mainly due to missing static resources. Below are the error logs:
[GIN] 2025/03/03 - 05:16:26 | 500 | 286.67µs | 10.244.7.180 | GET "/plugin/a0235af0-a275-430d-a111-02e4598cad83/asset/0dbcd12864243bfcd8c0c1898a3e0c37ea553c21a727800b0863a599a9660729.svg" 2025/03/03 05:16:38 factory.go:28: [ERROR]PluginDaemonInternalServerError: open storage/assets/57890a536487e870acd3bd8249ea405bb4fa59428d9ca24a4a46a8bc3f2057e8.svg: no such file or directory goroutine 457 [running]: runtime/debug.Stack() /usr/local/go/src/runtime/debug/stack.go:24 +0x5e github.com/langgenius/dify-plugin-daemon/internal/types/exception.InternalServerError({0x180b860, 0xc0003b6660}) /app/internal/types/exception/factory.go:27 +0x27 github.com/langgenius/dify-plugin-daemon/internal/server/controllers.GetAsset(0xc00056bd00) /app/internal/server/controllers/plugins.go:21 +0xd0 github.com/gin-gonic/gin.(*Context).Next(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 +0x2b github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginGroup.CheckingKey.func1(0xc00056bd00) /app/internal/server/middleware.go:24 +0x95 github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 +0x7a github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.LoggerWithConfig.func1(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 +0xe5 github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc000030000, 0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 +0x892 github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc000030000, {0x181dac0, 0xc000542000}, 0xc0004f8a20) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 +0x1b2 net/http.serverHandler.ServeHTTP({0xc0003b6570?}, {0x181dac0?, 0xc000542000?}, 0x6?) /usr/local/go/src/net/http/server.go:3142 +0x8e net/http.(*conn).serve(0xc000654480, {0x1820270, 0xc000491440}) /usr/local/go/src/net/http/server.go:2044 +0x5e8 created by net/http.(*Server).Serve in goroutine 105 /usr/local/go/src/net/http/server.go:3290 +0x4b4 [GIN] 2025/03/03 - 05:16:38 | 500 | 324.686µs | 10.244.7.180 | GET "/plugin/a0235af0-a275-430d-a111-02e4598cad83/asset/57890a536487e870acd3bd8249ea405bb4fa59428d9ca24a4a46a8bc3f2057e8.svg"

@raye-deng commented on GitHub (Mar 3, 2025): > Hello [@raye-deng](https://github.com/raye-deng)! I'm here to help you with any bugs, questions, or contributions you have. Let's work together to solve the issue you're facing. > > To resolve the "no available node, plugin not found" error when configuring the model provider in a self-hosted Dify version 1.0.0 setup, you can try downgrading the `dify-api` and `dify-web` services to version 0.15.3 in your `docker-compose.yaml` file. This workaround addresses the database connection issue in the `plugin_daemon` component in v1.0.0-beta, which causes the error [[1]](https://github.com/langgenius/dify/issues/13777). > > _To continue talking to [Dosu](https://dosu.dev), mention [@dosu](https://github.com/dosu)._ > > Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e44438b8-0968-4378-b86f-dabe3778732f?feedback_type=other) I think this is not the same issue. Apart from the failure of the configured model, other already configured models also report errors when opened, mainly due to missing static resources. Below are the error logs: ` [GIN] 2025/03/03 - 05:16:26 | 500 | 286.67µs | 10.244.7.180 | GET "/plugin/a0235af0-a275-430d-a111-02e4598cad83/asset/0dbcd12864243bfcd8c0c1898a3e0c37ea553c21a727800b0863a599a9660729.svg" 2025/03/03 05:16:38 factory.go:28: [ERROR]PluginDaemonInternalServerError: open storage/assets/57890a536487e870acd3bd8249ea405bb4fa59428d9ca24a4a46a8bc3f2057e8.svg: no such file or directory goroutine 457 [running]: runtime/debug.Stack() /usr/local/go/src/runtime/debug/stack.go:24 +0x5e github.com/langgenius/dify-plugin-daemon/internal/types/exception.InternalServerError({0x180b860, 0xc0003b6660}) /app/internal/types/exception/factory.go:27 +0x27 github.com/langgenius/dify-plugin-daemon/internal/server/controllers.GetAsset(0xc00056bd00) /app/internal/server/controllers/plugins.go:21 +0xd0 github.com/gin-gonic/gin.(*Context).Next(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 +0x2b github.com/langgenius/dify-plugin-daemon/internal/server.(*App).pluginGroup.CheckingKey.func1(0xc00056bd00) /app/internal/server/middleware.go:24 +0x95 github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/recovery.go:102 +0x7a github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.LoggerWithConfig.func1(0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/logger.go:249 +0xe5 github.com/gin-gonic/gin.(*Context).Next(...) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185 github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc000030000, 0xc00056bd00) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:633 +0x892 github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc000030000, {0x181dac0, 0xc000542000}, 0xc0004f8a20) /go/pkg/mod/github.com/gin-gonic/gin@v1.10.0/gin.go:589 +0x1b2 net/http.serverHandler.ServeHTTP({0xc0003b6570?}, {0x181dac0?, 0xc000542000?}, 0x6?) /usr/local/go/src/net/http/server.go:3142 +0x8e net/http.(*conn).serve(0xc000654480, {0x1820270, 0xc000491440}) /usr/local/go/src/net/http/server.go:2044 +0x5e8 created by net/http.(*Server).Serve in goroutine 105 /usr/local/go/src/net/http/server.go:3290 +0x4b4 [GIN] 2025/03/03 - 05:16:38 | 500 | 324.686µs | 10.244.7.180 | GET "/plugin/a0235af0-a275-430d-a111-02e4598cad83/asset/57890a536487e870acd3bd8249ea405bb4fa59428d9ca24a4a46a8bc3f2057e8.svg" `
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@JiangFFFF commented on GitHub (Mar 3, 2025):

I also encountered this problem.

@JiangFFFF commented on GitHub (Mar 3, 2025): I also encountered this problem.
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@LZW-Andrewlu commented on GitHub (Mar 3, 2025):

问题原因

  1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下：

Image

  1. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。

解决方案

  1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。
  2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。
  3. [INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin

==========================================================================

Problem Reasons

  1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows:

Image

  1. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear.

Solutions

  1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem.
  2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process.
@LZW-Andrewlu commented on GitHub (Mar 3, 2025): ### 问题原因 1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下： ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) 2. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。 ### 解决方案 1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。 2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。 3. `[INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin` ========================================================================== ### Problem Reasons 1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows: ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) 2. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear. ### Solutions 1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem. 2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process.
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@LZW-Andrewlu commented on GitHub (Mar 3, 2025):

Errors:

`[INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin

2025-03-03 14:26:42 2025/03/03 06:26:42 runtime_lifetime.go:76: [ERROR]init environment failed: failed to install dependencies: signal: killed, output: init process exited due to no activity for 120 seconds, retry in 30s
`
It's too short with 120s for downloading python environment!!! it always end with timeout errors when installing plugins.

@LZW-Andrewlu commented on GitHub (Mar 3, 2025): ### Errors: `[INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin 2025-03-03 14:26:42 2025/03/03 06:26:42 runtime_lifetime.go:76: [ERROR]init environment failed: failed to install dependencies: signal: killed, output: init process exited due to no activity for 120 seconds, retry in 30s ` It's too short with 120s for downloading python environment!!! it always end with timeout errors when installing plugins.
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@zhiwenliao commented on GitHub (Mar 3, 2025):

How to manually execute the Python dependency installation process.

@zhiwenliao commented on GitHub (Mar 3, 2025): How to manually execute the Python dependency installation process.
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Mar 3, 2025):

https://github.com/langgenius/dify/issues/14654#issuecomment-2693994065

@crazywoola commented on GitHub (Mar 3, 2025): https://github.com/langgenius/dify/issues/14654#issuecomment-2693994065
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@leechedan commented on GitHub (Mar 3, 2025):

need to config the pip sourse host, or timeout come to you

@leechedan commented on GitHub (Mar 3, 2025): need to config the pip sourse host, or timeout come to you
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@raye-deng commented on GitHub (Mar 4, 2025):

问题原因

  1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下：

Image

  1. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。

解决方案

  1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。
  2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。
  3. [INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin

==========================================================================

Problem Reasons

  1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows:

Image

  1. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear.

Solutions

  1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem.
  2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process.

此方法为能解决我的问题，通过源代码来看，是plugin模块为能在当前节点找到对应的插件导致的，确实也是插件安装加载异常导致的，所有的插件都不可用。我通过以下操作重置了所有的插件：

  1. 在psql的dify_plugin数据库执行以下语句清空插件安装、配置
    delete from plugin_installations where plugin_unique_identifier is not null; delete from plugin_declarations where plugin_unique_identifier is not null; delete from ai_model_installations where plugin_unique_identifier is not null; delete from plugins where plugin_unique_identifier is not null;
  2. 清空插件的安装、执行目录，相应目录对应环境变量示例如下：
    `
    • name: PLUGIN_INSTALLED_PATH
      value: "/app/storage/cwd/plugins/plugin"
    • name: PLUGIN_WORKING_PATH
      value: "/app/storage/cwd/plugins/plugin-working"
    • name: PERSISTENCE_STORAGE_PATH
      value: "/app/storage/cwd/plugins/persistence"
    • name: PLUGIN_STORAGE_LOCAL_ROOT
      value: "/app/storage/cwd/plugins/plugin-root"
      `
      3.重启plugin daemon服务
      4.重新安装插件

==========================================================================
This method can solve my problem. From the source code, it appears that the issue is caused by the plugin module being unable to find the corresponding plugin on the current node, which indeed results from abnormal installation and loading of the plugins, causing all plugins to be unavailable. I reset all plugins through the following operations:

  1. Executed the following statements in the dify_plugin database in psql to clear the plugin installations and configurations.
    delete from plugin_installations where plugin_unique_identifier is not null; delete from plugin_declarations where plugin_unique_identifier is not null; delete from ai_model_installations where plugin_unique_identifier is not null; delete from plugins where plugin_unique_identifier is not null;

  2. Clear the installation and execution directories of the plugin, the corresponding environment variable examples are as follows:
    `

    • name: PLUGIN_INSTALLED_PATH
      value: "/app/storage/cwd/plugins/plugin"
    • name: PLUGIN_WORKING_PATH
      value: "/app/storage/cwd/plugins/plugin-working"
    • name: PERSISTENCE_STORAGE_PATH
      value: "/app/storage/cwd/plugins/persistence"
    • name: PLUGIN_STORAGE_LOCAL_ROOT
      value: "/app/storage/cwd/plugins/plugin-root"
      `

  3. Restart the plugin daemon service

  4. Reinstall the plugin

==========================================================================
最后的建议：

  1. 希望提供强制重新安装、覆盖插件的功能，以解决插件加载异常带来的问题。不论是使用本地安装包还是使用插件市场的安装，至少应该有重置的入口。我所碰到的问题是即便我删除了插件再重新安装，似乎并没有触发安装任务，而是直接复用了之前的安装配置，导致插件无论如何都无法使用。
  2. 能理解插件生态带来的优势，但是希望和其他模块的服务一样，在对应的插件仓库中提供完整的环境变量配置、功能说明

Final Suggestions:

  1. Hope to provide a function for mandatory reinstallation and plugin overwrite to solve the problems caused by plugin loading exceptions. Whether using local installation packages or installation from the plugin market, at least there should be an entry for reset. The problem I encountered is that even after I deleted the plugin and reinstalled it, it seems that the installation task was not triggered, but the previous installation configuration was reused directly, causing the plugin to be unusable no matter what.

  2. Understand the advantages brought by the plugin ecosystem, but hope that like other module services, complete environment variable configuration and functional descriptions are provided in the corresponding plugin repository.

@raye-deng commented on GitHub (Mar 4, 2025): > ### 问题原因 > 1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下： > > ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) > > 2. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。 > > ### 解决方案 > 1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。 > 2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。 > 3. `[INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin` > > ========================================================================== > > ### Problem Reasons > 1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows: > > ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) > > 2. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear. > > ### Solutions > 1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem. > 2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process. 此方法为能解决我的问题，通过源代码来看，是plugin模块为能在当前节点找到对应的插件导致的，确实也是插件安装加载异常导致的，所有的插件都不可用。我通过以下操作重置了所有的插件： 1. 在psql的dify_plugin数据库执行以下语句清空插件安装、配置 ` delete from plugin_installations where plugin_unique_identifier is not null; delete from plugin_declarations where plugin_unique_identifier is not null; delete from ai_model_installations where plugin_unique_identifier is not null; delete from plugins where plugin_unique_identifier is not null; ` 2. 清空插件的安装、执行目录，相应目录对应环境变量示例如下： ` - name: PLUGIN_INSTALLED_PATH value: "/app/storage/cwd/plugins/plugin" - name: PLUGIN_WORKING_PATH value: "/app/storage/cwd/plugins/plugin-working" - name: PERSISTENCE_STORAGE_PATH value: "/app/storage/cwd/plugins/persistence" - name: PLUGIN_STORAGE_LOCAL_ROOT value: "/app/storage/cwd/plugins/plugin-root" ` 3.重启plugin daemon服务 4.重新安装插件 ========================================================================== This method can solve my problem. From the source code, it appears that the issue is caused by the plugin module being unable to find the corresponding plugin on the current node, which indeed results from abnormal installation and loading of the plugins, causing all plugins to be unavailable. I reset all plugins through the following operations: 1. Executed the following statements in the dify_plugin database in psql to clear the plugin installations and configurations. ` delete from plugin_installations where plugin_unique_identifier is not null; delete from plugin_declarations where plugin_unique_identifier is not null; delete from ai_model_installations where plugin_unique_identifier is not null; delete from plugins where plugin_unique_identifier is not null; ` 2. Clear the installation and execution directories of the plugin, the corresponding environment variable examples are as follows: ` - name: PLUGIN_INSTALLED_PATH value: "/app/storage/cwd/plugins/plugin" - name: PLUGIN_WORKING_PATH value: "/app/storage/cwd/plugins/plugin-working" - name: PERSISTENCE_STORAGE_PATH value: "/app/storage/cwd/plugins/persistence" - name: PLUGIN_STORAGE_LOCAL_ROOT value: "/app/storage/cwd/plugins/plugin-root" ` 3. Restart the plugin daemon service 4. Reinstall the plugin ========================================================================== 最后的建议： 1. 希望提供强制重新安装、覆盖插件的功能，以解决插件加载异常带来的问题。不论是使用本地安装包还是使用插件市场的安装，至少应该有重置的入口。我所碰到的问题是即便我删除了插件再重新安装，似乎并没有触发安装任务，而是直接复用了之前的安装配置，导致插件无论如何都无法使用。 2. 能理解插件生态带来的优势，但是希望和其他模块的服务一样，在对应的插件仓库中提供完整的环境变量配置、功能说明 Final Suggestions: 1. Hope to provide a function for mandatory reinstallation and plugin overwrite to solve the problems caused by plugin loading exceptions. Whether using local installation packages or installation from the plugin market, at least there should be an entry for reset. The problem I encountered is that even after I deleted the plugin and reinstalled it, it seems that the installation task was not triggered, but the previous installation configuration was reused directly, causing the plugin to be unusable no matter what. 2. Understand the advantages brought by the plugin ecosystem, but hope that like other module services, complete environment variable configuration and functional descriptions are provided in the corresponding plugin repository.
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@raye-deng commented on GitHub (Mar 4, 2025):

@crazywoola ⬆️

@raye-deng commented on GitHub (Mar 4, 2025): @crazywoola ⬆️
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@ssqwqwqwqw commented on GitHub (Mar 19, 2025):

遇到类似问题报错，求大神解答[ERROR]init environment failed: failed to create virtual environment: exit status 1, output: Error: [Errno 1] Operation not permitted: 'lib' -> '/app/storage/cwd/langgenius/deepseek-0.0.5@fd6efd37c2a931911de8ab9ca3ba2da303bef146d45ee87ad896b04b36d09403/.venv/lib64'

@ssqwqwqwqw commented on GitHub (Mar 19, 2025): 遇到类似问题报错，求大神解答[ERROR]init environment failed: failed to create virtual environment: exit status 1, output: Error: [Errno 1] Operation not permitted: 'lib' -> '/app/storage/cwd/langgenius/deepseek-0.0.5@fd6efd37c2a931911de8ab9ca3ba2da303bef146d45ee87ad896b04b36d09403/.venv/lib64'
yindo commented 2026-02-21 18:28:22 -05:00
Author
Owner
Copy Link
Copy Source

@lsCoding666 commented on GitHub (Apr 10, 2025):

问题原因

  1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下：

Image

  1. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。

解决方案

  1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。
  2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。
  3. [INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin

==========================================================================

Problem Reasons

  1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows:

Image

  1. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear.

Solutions

  1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem.
  2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process.

这个重新执行执行python 依赖安装流程。如何执行，使用的是哪个python环境执行pip install -r requirement.txt?

@lsCoding666 commented on GitHub (Apr 10, 2025): > ### 问题原因 > 1. 问题原因是插件安装异常，大部分插件都是python编写的源代码工程，在安装时插件会进行python依赖库的安装，安装过程非常缓慢，通过docker-plugin_daemon 服务日志可以看到，插件基本都卡在依赖安装这一步超时，安装失败截图如下： > > ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) > > 2. 插件安装失败，但web界面上已根据数据库存储的插件描述信息显示在界面上，因此使用插件时会因为插件系统并未正常加载，所以会各种报错提示。 > > ### 解决方案 > 1. 不得不说，这个插件系统开发的有点让人喷饭，插件安装慢不说，还各种安装不成功。安装异常后不知道如何解决。通过VPN翻墙也无法解决。 > 2. 手动转到“dify-main\docker\volumes\plugin_daemon\cwd\langgenius”目录下，找到问题插件目录，手动执行python 依赖安装流程。 > 3. `[INFO]installing langgenius/ollama:0.0.3 - Installing collected packages: pydub, dpkt, urllib3, typing-extensions, socksio, sniffio, setuptools, regex, pyyaml, python-dotenv, numpy, multidict, MarkupSafe, itsdangerous, idna, h11, greenlet, click, charset-normalizer, certifi, blinker, annotated-types, zope.interface, zope.event, yarl, Werkzeug, requests, pydantic-core, Jinja2, httpcore, anyio, tiktoken, pydantic, httpx, gevent, Flask, pydantic_settings, dify_plugin` > > ========================================================================== > > ### Problem Reasons > 1. The reason for the problem is that the plugin installation is abnormal. Most of the plugins are source code projects written in Python. When installing the plugins, the installation of Python dependency libraries will be carried out. The installation process is very slow. As can be seen from the logs of the docker-plugin_daemon service, most of the plugins are basically stuck at the step of installing dependencies and time out. The screenshot of the installation failure is as follows: > > ![Image](https://github.com/user-attachments/assets/2518b3e7-b536-432c-ac94-a97884abd2dc) > > 2. The plugin installation fails, but the plugin has been displayed on the web interface according to the plugin description information stored in the database. Therefore, when using the plugin, since the plugin system is not loaded properly, various error prompts will appear. > > ### Solutions > 1. It has to be said that the development of this plugin system is a bit ridiculous. Not only is the plugin installation slow, but also various installation failures occur. We don't know how to solve the problem after the installation is abnormal. Using a VPN to bypass the firewall also cannot solve the problem. > 2. Manually navigate to the directory "dify-main\docker\volumes\plugin_daemon\cwd\langgenius", find the directory of the problematic plugin, and manually execute the Python dependency installation process. 这个重新执行执行python 依赖安装流程。如何执行，使用的是哪个python环境执行pip install -r requirement.txt?
yindo commented 2026-02-21 18:28:23 -05:00
Author
Owner
Copy Link
Copy Source

@LiQiongchao commented on GitHub (Apr 11, 2025):

我的解决方法如下

  1. 进入容器
    docker exec -it docker-plugin_daemon-1 bash
  2. 找到插件的目录
    cd /app/storage/cwd/langgenius/ollama-0.0.5@xxxx
  3. 安装依赖
    pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
@LiQiongchao commented on GitHub (Apr 11, 2025): 我的解决方法如下 1. 进入容器 `docker exec -it docker-plugin_daemon-1 bash` 2. 找到插件的目录 `cd /app/storage/cwd/langgenius/ollama-0.0.5@xxxx` 3. 安装依赖 `pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple`
yindo commented 2026-02-21 18:28:23 -05:00
Author
Owner
Copy Link
Copy Source

@ylck commented on GitHub (May 20, 2025):

我的解决方法如下

  1. 进入容器
    docker exec -it docker-plugin_daemon-1 bash
  2. 找到插件的目录
    cd /app/storage/cwd/langgenius/ollama-0.0.5@xxxx
  3. 安装依赖
    pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

也可以参考 https://help.mirrorz.org/pypi/#astral-uv

在 ~/.config/uv/uv.toml 或者 /etc/uv/uv.toml 填写下面的内容：

url = "https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple"
default = true
@ylck commented on GitHub (May 20, 2025): > 我的解决方法如下 > > 1. 进入容器 > `docker exec -it docker-plugin_daemon-1 bash` > 2. 找到插件的目录 > `cd /app/storage/cwd/langgenius/ollama-0.0.5@xxxx` > 3. 安装依赖 > `pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple` > 也可以参考 https://help.mirrorz.org/pypi/#astral-uv > 在 ~/.config/uv/uv.toml 或者 /etc/uv/uv.toml 填写下面的内容： ```[[index]] url = "https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple" default = true ```
yindo commented 2026-02-21 18:28:23 -05:00
Author
Owner
Copy Link
Copy Source

@nickhelion commented on GitHub (Jun 8, 2025):

https://help.mirrorz.org/pypi/#astral-uv
Maybe set env in .env is better, editting file inside container may not persist, only for your referenece
PIP_MIRROR_URL=https://pypi.tuna.tsinghua.edu.cn/simple

@nickhelion commented on GitHub (Jun 8, 2025): > https://help.mirrorz.org/pypi/#astral-uv Maybe set env in .env is better, editting file inside container may not persist, only for your referenece PIP_MIRROR_URL=https://pypi.tuna.tsinghua.edu.cn/simple
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#8882
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?