Repository navigation
feat: Evaluate Python dependency source precedence #4476
Description
I’d prefer a lockfile or pyproject.toml over requirements.txt, which can be a stale export. Currently, an existing requirements file always wins.
✓ = present; — = absent. Default configuration, valid dependency sources, and no pylock.toml.
requirements.txt |
pyproject.toml |
uv.lock |
Selected source |
|---|---|---|---|
| — | — | — | Import scan¹ |
| ✓ | — | — | Requirements |
| — | ✓ | — | Pyproject |
| — | — | ✓ | uv lock |
| ✓ | ✓ | — | Requirements |
| ✓ | — | ✓ | Requirements |
| — | ✓ | ✓ | uv lock |
| ✓ | ✓ | ✓ | Requirements |
pylock.toml takes precedence over uv and pyproject, but not requirements.
¹ Automatic scanning is under Unreleased in the inspected changelog. It writes requirements.txt, which then wins on later deployments.
Could we reconsider this order and let users explicitly select deployment-specific requirements?
Activity
karawoo commentedon Nov 13, 2026
I think this makes sense and ideally we'd have consistent behavior with rsconnect-python. I see you filed an issue there as well.
Seems like a good first step would be to allow
package_fileto acceptuv.lock,pylock.toml, andpyproject.toml(which rsconnect-python already allows with-r). Changing the default precedence order seems feasible too; projects that already havepackage_file = "requirements.txt"could continue using that so they don't get unexpected results during their next deploy.