Goal

Document the one-time PyPI Trusted Publishing setup required before the first release of a new library in this monorepo, and link it from RELEASE.md.

Why

RELEASE.md describes the steady-state release process and silently assumes trusted publishing is already configured. That assumption holds for the three published libraries, but not for a new one.

Trusted publishing cannot attach a publisher to a project that does not exist yet, so a brand-new package needs a pending publisher registered by hand on PyPI first. Without it the release run fails at the publish step — after a green build, and after the version bump has already been merged.

This came up directly while preparing the first langchain-mongodb-deepagents-vfs release, where the requirement was not discoverable from the repo and had to be reconstructed from PyPI documentation and warehouse source.

Changes

What the document covers

• Why a pending publisher is needed, and what fails without one.
• The exact form fields for this repo: owner langchain-ai, repository langchain-mongodb, workflow _release.yml, environment left empty.
• Why the workflow-name field is the file containing the publish job rather than the workflow that gets dispatched. Verified against warehouse source: the job_workflow_ref claim is checked at warehouse/oidc/models/github.py:156 and compared against .github/workflows/{workflow_filename} at line 242. Also notes that this field must change if the publish job is ever moved into a reusable workflow.
• Why the environment field must be left blank — PyPI's UI calls it "strongly recommended", but the publish job declares no environment:, and a mismatched claim is rejected. Flags that this must be revisited if environment: is ever added.
• Gotchas: a pending publisher does not reserve the project name until first upload; metadata is validated locally by validate-pyproject and twine check --strict in the build job.
• A verification snippet for confirming the name is still unclaimed before releasing.
• A note that both publish steps set attestations: false, so releases are not signed — independent of this setup, but easy to assume otherwise.

Acceptance criteria

• A developer preparing the first release of a new library can complete the PyPI setup from RELEASE.md without external research.
• Stated field values match what _release.yml actually requires.
• No stale references to TestPyPI, which was removed under INTPYTHON-1069.

Notes

• Written against the post-INTPYTHON-1069 world: only PyPI needs a publisher now. An earlier draft covered TestPyPI as a second registration; that section is gone.