# How to Verify if a Repackaged Dify Plugin Works Correctly: Complete Technical Guide

> Verify a repackaged Dify plugin works by checking extraction, bundled wheels, local requirements, and successful offline installation. Ensure your plugin functions correctly.

- Repository: [Junjie.M/dify-plugin-repackaging](https://github.com/junjiem/dify-plugin-repackaging)
- Tags: how-to-guide
- Published: 2026-03-05

---

**You can verify a repackaged Dify plugin by confirming successful extraction of the original package, validating that all Python wheels are bundled in the `wheels/` directory, checking that [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) points to local wheels with `--no-index`, and successfully installing the final offline package on a Dify instance without network errors.**

The `junjiem/dify-plugin-repackaging` repository provides a Bash automation script that converts standard Dify plugins into self-contained offline packages for air-gapped environments. When you repackage a plugin using [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh), systematic verification ensures that all dependencies are correctly bundled and the final `.difypkg` file installs without requiring external network access.

## Understanding the Repackaging Verification Checkpoints

The verification process in [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh) follows three critical checkpoints that map to specific functions in the source code:

- **Download and Extraction**: The `market()` or `github()` functions fetch the original `.difypkg` file, while `repackage()` handles extraction via `unzip` (lines 38-50, 64-76, and 99-106).
- **Dependency Bundling**: The `repackage()` function executes `pip download` to populate the `wheels/` directory and patches [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) using `sed` (lines 13 and 19-25).
- **Re-packaging**: The Dify CLI binary (`dify-plugin-<os>-<arch>`) rebuilds the package via `${CMD_NAME} plugin package` (line 40), producing the final offline-ready file.

## Step-by-Step Verification of Your Repackaged Dify Plugin

### Confirm Download and Extraction Success

When you execute the repackaging script, first verify that the original package downloads correctly. For marketplace plugins, run:

```bash
./plugin_repackaging.sh market junjiem mcp_sse 0.0.1

```

The script should output `Downloading https://marketplace.dify.ai/api/v1/plugins/junjiem/mcp_sse/0.0.1/download ...` followed by `Unzip success.` This confirms that the `unzip` command in the `repackage()` function successfully extracted the plugin manifest and source files.

### Validate the Bundled Python Wheels

After extraction, the script downloads all Python dependencies into a local `wheels/` directory. Verify this checkpoint by checking the directory contents:

```bash
cd mcp_sse_0.0.1  # The extraction directory created by the script

ls wheels/

```

You should see `.whl` files corresponding to every package listed in the original [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt). The `pip download` command executed at line 13 of the `repackage()` function ensures all dependencies are resolved for the target platform without requiring installation.

### Verify the Patched requirements.txt

The repackaging process modifies [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) to enable offline installation. Check that the file begins with the local wheel configuration:

```bash
head -n 1 requirements.txt

```

The output must be:

```text
--no-index --find-links=./wheels/

```

This line is inserted by the `sed` command at lines 19-25 of the `repackage()` function. The `--no-index` flag prevents pip from contacting PyPI, while `--find-links` directs it to the bundled wheels directory.

### Check the Final Offline Package Generation

The final verification step confirms that the Dify CLI successfully rebuilds the package. The script executes `${CMD_NAME} plugin package` at line 40, where `CMD_NAME` resolves to the platform-specific binary (e.g., `dify-plugin-linux-amd64`).

Upon success, the script outputs `Repackage success.` and creates a file named `<PLUGIN_NAME>-offline.difypkg` (or using your custom `${PACKAGE_SUFFIX}`). Verify the file exists:

```bash
ls -lh *-offline.difypkg

```

### Install and Test on a Dify Instance

To complete functional verification, install the repackaged plugin on a Dify instance:

1. Navigate to **Plugin Management** in the Dify console.
2. Select **Local Package File** and upload your `*-offline.difypkg` file.
3. Verify the plugin appears in the **Installed Plugins** list without network errors.

Run a functional test by creating a workflow that invokes the plugin. Monitor the container logs to confirm no outbound requests to `pypi.org` occur during plugin initialization, which proves the offline bundling succeeded.

## Code Examples for Automated Verification

Use these commands to automate the verification checklist:

```bash

# Repackage a marketplace plugin

./plugin_repackaging.sh market junjiem mcp_sse 0.0.1

# Verify extraction and wheel bundling

if [ -d "mcp_sse_0.0.1/wheels" ] && [ "$(ls -A mcp_sse_0.0.1/wheels)" ]; then
    echo "✓ Wheels bundled successfully"
fi

# Verify requirements.txt patching

if head -n 1 mcp_sse_0.0.1/requirements.txt | grep -q "no-index"; then
    echo "✓ Requirements.txt patched for offline use"
fi

# Verify final package creation

if [ -f "mcp_sse-0.0.1-offline.difypkg" ]; then
    echo "✓ Offline package created successfully"
fi

```

## Summary

- **Download and extraction** must complete with `Unzip success.` output from the `repackage()` function in [`plugin_repackaging.sh`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/plugin_repackaging.sh).
- **Wheel bundling** requires the `wheels/` directory to contain `.whl` files for all dependencies resolved by the `pip download` command.
- **Requirements patching** must insert `--no-index --find-links=./wheels/` at the top of [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) via the `sed` command.
- **Package generation** succeeds when the Dify CLI binary (`dify-plugin-<os>-<arch>`) creates the `*-offline.difypkg` file without errors.
- **Functional verification** confirms the plugin installs and executes on a Dify instance without requiring network access to PyPI.

## Frequently Asked Questions

### What is the purpose of the wheels/ folder in a repackaged Dify plugin?

The `wheels/` folder contains all Python dependency packages downloaded as `.whl` files by the `pip download` command in the `repackage()` function. This directory enables offline installation by providing local copies of every package listed in [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt), eliminating the need for the Dify instance to connect to PyPI during plugin initialization.

### How does the repackaging script modify requirements.txt for offline use?

The script uses `sed` at lines 19-25 of the `repackage()` function to insert `--no-index --find-links=./wheels/` at the beginning of [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt). The `--no-index` flag instructs pip to ignore PyPI, while `--find-links` directs it to search for packages in the local `wheels/` directory, creating a fully self-contained dependency resolution mechanism.

### Can I verify a repackaged plugin without installing it on Dify?

Yes, you can perform local verification by checking for the `Unzip success.` message after extraction, confirming the `wheels/` directory contains `.whl` files for all dependencies, verifying that [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) starts with the offline configuration flags, and ensuring the final `*-offline.difypkg` file exists. However, functional verification requires installing the plugin on a Dify instance to confirm it loads and executes without network errors.

### What should I do if the Dify CLI fails to create the offline package?

If the `${CMD_NAME} plugin package` command fails at line 40 of the `repackage()` function, first verify that the Dify CLI binary (`dify-plugin-<os>-<arch>`) has execute permissions and matches your system architecture. Check that the working directory contains a valid [`requirements.txt`](https://github.com/junjiem/dify-plugin-repackaging/blob/main/requirements.txt) and `wheels/` folder. Ensure the original plugin package was not corrupted during download by verifying the `Unzip success.` message appeared earlier in the output. If errors persist, check the Dify CLI output for specific packaging errors related to manifest validation or file permissions.