feat: package Python plugins with uv lock dependencies #719

Self Checks

To make sure we get to you in time, please check the following :)

• I have searched for existing issues, including closed ones.
• I confirm that I am using English to submit this report.
• This report is submitted in English.
• "Please do not modify this template :) and fill in all the required fields."

Is your feature request related to a problem? Please describe.
Python plugin templates should treat pyproject.toml and uv.lock as the dependency source of truth, but the current packaging defaults can exclude the lockfile and do not automatically provide a legacy requirements.txt inside the generated .difypkg. This creates drift risk for official plugins and compatibility risk for package consumers that still expect requirements.txt in packaged Python plugins.

Describe the solution you'd like
Update cmd/commandline/plugin/templates/python/.difyignore so it no longer excludes uv.lock. Keep ignoring runtime-unrelated local files such as .venv/, __pycache__/, test caches, and build artifacts. New Python plugins should include both pyproject.toml and uv.lock by default when packaged.

Update cmd/commandline/plugin/templates/python/.gitignore so it no longer ignores uv.lock, while still keeping local environments, caches, and build artifacts out of version control. This should align with the strategy that official plugins use pyproject.toml + uv.lock as the dependency source of truth.

When dify plugin package packages a Python plugin, detect pyproject.toml + uv.lock and use uv export to generate a legacy requirements.txt from uv.lock. The generated file should be written only into the final .difypkg; it must not be written into or leave behind changes in the plugin source directory.

Recommended uv export arguments:

--frozen
--format requirements.txt
--no-group dev
--no-emit-project
--no-hashes
--no-header
--no-annotate

Add packaging coverage that verifies:

• The package contains pyproject.toml.
• The package contains uv.lock.
• The package contains the generated requirements.txt.
• The source directory does not get a new requirements.txt after packaging.

Describe alternatives you've considered
Continue requiring plugins to maintain a checked-in requirements.txt, but that duplicates dependency state and can drift from pyproject.toml + uv.lock.

Generate requirements.txt directly in the plugin source directory before packaging, but that pollutes the working tree and creates an artifact that is only needed for the packaged output.

Omit requirements.txt entirely from the package, but that is less compatible while package consumers or runtime paths still depend on the legacy file.

Additional context
This issue is intended to line up plugin daemon packaging behavior with langgenius/dify-official-plugins#2965, which migrated official Python plugins from requirements.txt to pyproject.toml + uv.lock. After that repository-level migration, the daemon packaging path should preserve the lockfile in Python plugin packages and generate a legacy requirements.txt only inside the .difypkg output for runtime compatibility.

This change should make Python plugin packaging compatible with lockfile-based dependency management while preserving legacy package contents for runtimes that consume requirements.txt.