[Proposal] Deprecate Python plugin framework and consolidate on Go

まず backend/python/、backend/Dockerfile、Dockerfile.local、.github/workflows/test.yml、.github/workflows/test-e2e.yml、および記載されている Make targets を確認します。次に、Python azuredevops plugin と azuredevops_go を比較し、特に CI/CD 環境の抽出に注目します。maintainers が提案に合意し、警告、移行、削除の各フェーズの担当者が特定されれば完了です。

Proposal: Deprecate the Python plugin framework and consolidate on Go

Summary

Propose to deprecate the Python plugin framework (backend/python/, a.k.a. PyDevLake) and remove it from the codebase after a 3-month deprecation window. Going forward, all plugins should be written in Go. This reduces maintenance overhead, simplifies the Docker image and CI, and focuses contributor effort on a single, well-supported runtime.

Background

The Python plugin framework was introduced in Feb 2023 (#3702, #4438) to lower the barrier for writing plugins. In practice it never saw adoption:

• Only one plugin ever shipped on it: azuredevops (Python).
• The dbt Python plugin was already removed on 2026-08-31 (#8970).
• A fully-featured Go implementation, azuredevops_go, now exists and is actively developed (on-premises support landed 2026-08-16, #9014).

Evidence: Python plugins are not being maintained

In the last ~12 months, the only commits touching backend/python/ are dependency refreshes, Poetry/uv lock bumps, a Python 3.9→3.11 runtime bump, and a single primary-key fix. Meanwhile the Go side shipped 40+ plugins and continues to receive features weekly.

Benefits

1. One runtime to maintain. Eliminate the parallel PyDevLake framework, its RPC bridge, pydevlake package, uv/Poetry tooling, and Python-specific test/build scripts.
2. Simpler Docker build. Today backend/Dockerfile is based on python:3.11-slim-bookworm, installs python3-dev/pip/uv, copies python/, and runs build.sh. After removal the image can be a slim Go-based image — smaller, fewer CVEs, faster builds. Dockerfile.local's "empty python plugins dir" workaround also goes away.
3. Simpler CI. Two workflows (.github/workflows/test.yml, test-e2e.yml) and Make targets (python-dep, python-unit-test, build-python, build-pydevlake) can be dropped.
4. Clearer contributor story. New plugin authors get one path (Go) with 40+ reference implementations instead of choosing between two frameworks where one is unmaintained.
5. No functional loss. The only remaining Python plugin (azuredevops) is superseded by azuredevops_go, which already has broader feature coverage (Server/on-prem support).

Plan & Timeline

Total deprecation window: 3 months from the date this proposal is accepted.

Risks & Mitigations

• Existing users of azuredevops (Python): Mitigated by azuredevops_go parity + migration guide in Phase 3. The Go plugin already covers cloud + on-prem.
• External contributors with in-progress Python plugins: The 3-month window + the warning phase gives them time to port. No private Python plugins are known to exist in the wild.
• Reverting later: Not needed; Go covers all current and planned use cases.

What we need

• 👍 / 👎 from maintainers and community on deprecating Python.
• Owners to confirm azuredevops_go feature parity with the Python azuredevops plugin (esp. CI/CD environment extraction).
• Volunteers to write the Phase-3 migration guide.