Openai-api-compatible 0.0.53 plugin package contains direct files.pythonhosted.org URLs and fails in offline/proxied environments

[enix-zed]

Self Checks

• I have read the Contributing Guide and Language Policy.
• 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, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.13.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Summary

The openai-api-compatible plugin package version 0.0.53 appears to contain hardcoded external package URLs (for example https://files.pythonhosted.org/...) inside the packaged dependency metadata / lock file.

Because of this, plugin installation in Dify does not fully respect the configured private PyPI proxy and fails in offline or air-gapped environments, even when PIP_INDEX_URL / UV_INDEX_URL are correctly configured and working.

---

Environment

• Dify version: 1.13.3
• Deployment: Kubernetes
• Plugin: openai-api-compatible
• Upgrade path: 0.0.37 -> 0.0.53
• Environment type: air-gapped / no direct internet access
• Private PyPI proxy is available and reachable from the cluster

Configured in plugin-daemon:

• PIP_INDEX_URL=http://<private-pypi-proxy>/repository/pypi-proxy/simple
• PIP_TRUSTED_HOST=<private-pypi-proxy-host>
• UV_INDEX_URL=http://<private-pypi-proxy>/repository/pypi-proxy/simple
• UV_INDEX_STRATEGY=unsafe-best-match

---

Problem

Installing or upgrading the plugin from the Dify UI fails with errors similar to:

failed to launch plugin: failed to install dependencies: failed to install dependencies: exit status 1, output:
...
error sending request for url
(https://files.pythonhosted.org/packages/.../gevent-26.5.0-cp312-cp312-manylinux_2_28_x86_64.whl)
client error (Connect)
operation timed out
...

We observed the same pattern for other packages as well, such as:

• blinker
• zope-interface
• gevent

---

Important findings

1. The private PyPI proxy is reachable from the plugin-daemon pod.
2. The environment variables are correctly present inside the plugin-daemon container.
3. Manual installation from inside the same pod works fine through the private proxy:

uv pip install --system -vvv "blinker==1.9.0"
uv pip install --system -vvv "zope-interface==8.4"
uv pip install --system -vvv greenlet
uv pip install --system -vvv "gevent==26.5.0"

All of the above succeeded.

4. However, during plugin installation from the Dify UI, the logs still show many direct requests to:

• https://files.pythonhosted.org/...

5. After inspecting the unpacked plugin content, we found many references to files.pythonhosted.org inside the packaged plugin files.

This strongly suggests that the packaged plugin includes a lock file or dependency metadata with direct artifact URLs, causing uv to fetch wheels from files.pythonhosted.org directly instead of resolving everything through the configured private package index.

---

Regression note

• Version 0.0.37 worked in our environment.
• Version 0.0.53 fails and contains direct external URLs.

So this appears to be a regression introduced somewhere between 0.0.37 and 0.0.53.

---

Suspected root cause

Most likely the plugin package contains one of the following:

• uv.lock
• another lock file
• dependency metadata with direct wheel URLs

These direct URLs point to files.pythonhosted.org, which bypasses private package indexes and breaks offline installs.

---

Suggested fix

Please publish the plugin package in an offline-friendly way:

1. Do not ship a uv.lock (or other lock file) with direct external artifact URLs, or
2. Generate the lock/package metadata in a way that does not embed files.pythonhosted.org URLs, or
3. Ensure plugin installation resolves dependencies strictly through the configured package index instead of direct wheel URLs.

---

Why this matters

This makes the plugin impossible to install in enterprise / air-gapped / restricted-network deployments of Dify, even though a valid internal PyPI proxy is available and functional.

---

Workaround we are testing

Removing uv.lock from the packaged .difypkg may allow dependency resolution via the private index, but this is only a workaround and not a proper upstream fix.

---

If needed, I can also provide:

• example failing logs
• exact grep results showing files.pythonhosted.org inside the unpacked plugin package
• Kubernetes/Dify deployment details

✔️ Expected Behavior

The plugin package should be installable in offline / air-gapped / proxied environments as long as Dify's Python package resolver is configured with a private PyPI index.

In particular, the packaged plugin should not force direct downloads from files.pythonhosted.org.

❌ Actual Behavior

Even with a working private PyPI proxy and valid PIP_INDEX_URL / UV_INDEX_URL, plugin installation still attempts to download wheel files directly from files.pythonhosted.org, which fails in offline environments.

[enix-zed]

Workaround for offline / air-gapped environments

I spent a lot of time, but I found a workaround.

Additional Dify configuration

/app/storage must be a PVC.

What I did

1. Disabled plugin signature verification in Dify plugin-daemon using:

   - name: ENFORCE_LANGGENIUS_PLUGIN_SIGNATURES
     value: "false"
   - name: FORCE_VERIFYING_SIGNATURE
     value: "false"

2. Removed uv.lock from the .difypkg archive:

   cp langgenius-openai_api_compatible_0.0.53.difypkg \
      langgenius-openai_api_compatible_0.0.53_no_uvlock.difypkg
   
   zip -d langgenius-openai_api_compatible_0.0.53_no_uvlock.difypkg uv.lock

3. Uploaded the modified plugin package in the Dify UI (There may be will be an error).

4. After Dify unpacked the plugin into /app/storage/cwd/langgenius/..., I manually entered the plugin-daemon pod and ran uv sync inside the unpacked plugin directory using our internal PyPI proxy:

   kubectl exec -it -n <namespace> <plugin-daemon-pod> -- sh -lc '
   PLUGIN_DIR=$(find /app/storage/cwd/langgenius -maxdepth 1 -type d | grep "openai_api_compatible-0.0.53@" | tail -1)
   echo "PLUGIN_DIR=$PLUGIN_DIR"
   cd "$PLUGIN_DIR" || exit 1
   
   UV_INDEX_URL=http://<private-pypi-proxy>/repository/pypi-proxy/simple \
   PIP_INDEX_URL=http://<private-pypi-proxy>/repository/pypi-proxy/simple \
   PIP_TRUSTED_HOST=<private-pypi-proxy-host> \
   UV_INSECURE=true \
   uv sync -vvv
   '

5. After that, plugin installation / launch from the Dify UI was completed successfully.

Important notes

• This is only a workaround, not a proper fix.
• Removing uv.lock breaks the original plugin signature.
• Because of that, the plugin can only be installed if signature verification is disabled with:
  • ENFORCE_LANGGENIUS_PLUGIN_SIGNATURES=false
  • FORCE_VERIFYING_SIGNATURE=false
• This workaround may need to be repeated if the plugin working directory or uv environment is lost.
  - A proper upstream fix would be to publish the plugin package without direct external artifact URLs, or without a lock file that embeds files.pythonhosted.org links.