[deanq]

What

A runpod entry in a resource's dependencies=[...] (or requirements.txt) was installed at deploy time and then overlaid by sync_running_package, which copies the client's own runpod tree on top. The worker ran a silent mix of the two builds with no warning.

This fails the build when a declared dependency resolves to the runpod distribution, and points the user at the RUNPOD_PACKAGE_SPEC environment variable, which is the supported way to choose the worker's runpod build.

Why

dependencies is not a sound channel for pinning the SDK: the overlay always wins for the package tree while the pinned dist-info and any version-specific files remain, so the worker runs code the user did not pin. Failing fast with an actionable message is clearer than a mixed install that only surfaces as runtime behavior drift.

Changes

• reject_runpod_dependency, called in build_environment before any vendoring runs.
• Detection resolves a spec to its canonical distribution name, covering plain version pins and runpod wheel/sdist URLs (and #egg= fragments), without tripping on lookalikes like runpodctl or my-runpod-helper.

Test plan

• reject_runpod_dependency: rejects bare runpod, runpod==X, runpod>=X, case variants, a wheel URL, a plain runpod.tar.gz URL, and a local sdist path; passes numpy, requests, runpod-cleanup, run_pod (a different distribution), and non-runpod URLs.
• build_environment raises before vendor is called when a resource lists runpod in dependencies.
• Full suite green locally: 2789 passed, coverage 94.36%.

Known gap (out of scope): a git+<repo> ref to the runpod repo with no #egg= fragment is not caught by filename parsing; version pins and wheel/sdist URLs are covered.