Run pipenv requirements to write a requirements.txt from Pipfile.lock, then use that file as the version source for your next tool, for example as constraints. The lock already holds exact versions, so the export keeps them. Do the export from an up to date lock, and check it with pipenv verify first.
Start from a lock you trust
Pipenv's own command list describes several relevant commands: lock generates Pipfile.lock with dependencies and hashes, verify checks that the Pipfile.lock hash is up to date, and requirements generates a requirements.txt from Pipfile.lock. Run verify before you export. If the lock is stale compared with the Pipfile, the export would record versions that nobody reviewed.
The install command can change the lock, so do not use it as your check. The Pipenv documentation says that before 2024 install relocked every time, and it now only updates the lock when adding or changing a package. For a read only check of the lock, use verify, and for installing exactly what the lock says, the docs recommend sync, which never tries to relock.
Steps
- Run the verify command and fix any mismatch.
- Export the default packages. Pipenv supports development and custom categories, so check the help output for how to include the ones your Pipfile defines.
- Commit the exported files on a branch next to the Pipfile.lock.
- Import them into the new tool as pinned constraints.
- Diff the resolved versions (see the link at the end).
- Remove the Pipfile and Pipfile.lock only after a release has shipped from the new setup.
pipenv verify
pipenv requirements > requirements.txt
Check the help output for your Pipenv version, because options such as category selection vary by release.
Pick a destination
| If you move to | Use the exported file as |
|---|---|
| uv project | Constraints on uv add, as in the uv migration guide |
| pip with hash checking | A pinned requirements file, installed with hash checking |
| Poetry | A reference list to compare versions after poetry add |
The uv guide shows importing a loose requirements file together with a pinned file as constraints so existing versions are retained. See move requirements.txt to uv without changing versions for the detail.
What you can lose
Pipfile.lock stores hashes. Confirm the exported file still carries them if your new install path checks them. If you drop hash checking in the move, you lose a protection against a substituted file, so say so explicitly in the pull request rather than letting it happen by accident.
Finally, check how the new tool handles indexes. A Pipfile source section may point at a private index, and the equivalent setting in the new tool needs to be as strict. The risk with several indexes is covered in why pip extra index url is unsafe for private packages.
Safeguard's dependency scanning can inventory the project before and after, and the free scan at gold.safeguard.sh/scan is a quick way to compare.
Quick check
Is pipenv install a safe way to deploy from the lock?
For deployments the Pipenv docs recommend sync, which installs from Pipfile.lock without ever relocking. Install may relock in some cases.
Do exported requirements keep hashes?
Pipenv lock records hashes, but confirm your exported file includes them for your version before relying on hash checking.
Sources
Last reviewed: 19 October 2026.
