A small group, usually platform plus security, should own a shared constraints file, with service teams able to propose changes by pull request. A pip constraints file limits versions across projects without installing anything, so one edit can affect every Python service that uses it.
What a constraints file is
The pip documentation describes constraints files as a way to specify global version limits for packages. They differ from requirements files in one key way: including a package in a constraints file does not trigger its installation.
Each line is a named package with a version specifier. You pass the file with the c option, and the documentation says it can also be served from a URL.
The example in the docs fits our topic. A package you do not install directly depends on a package that has a bug, and a constraints file can pin a patched version wherever it appears.
Why this raises an ownership question
Because a constraint can come from a URL, teams can point many pipelines at one central file. That is convenient, and it also means a change affects all of them at once.
Typical disputes follow.
- A team needs an older version for a legacy service, and the central file blocks it.
- Security adds a lower bound for an advisory, and a service build fails the next morning.
- Nobody remembers why a pin exists, so nobody dares remove it.
A workable ownership model
| Role | Responsibility |
|---|---|
| Platform team | Maintains the file, reviews changes, publishes it |
| Security | Proposes bounds for advisories, supplies the evidence |
| Service teams | Request exceptions, test changes in a branch |
| Each service | Keeps a local constraints file for service specific needs |
Split constraints into two layers. The shared file holds limits that should apply everywhere, such as a fixed minimum for a library with a serious advisory. Each service keeps its own file for the rest. You can pass more than one constraints file, so the local file adds to the shared one.
Rules for the shared file
- Every line has a comment with the reason and a review date.
- Use lower bounds for security fixes where you can, instead of exact pins, so teams can move forward.
- Changes go through a pull request with a test run from at least two representative services.
- Announce changes in the engineering channel before they merge.
- Remove lines when the underlying packages have moved on.
A note on build isolation
The pip documentation says that as of pip 26.2, regular constraints no longer affect isolated build environments, and a separate build constraint option exists for that. If you rely on constraints to control build dependencies, check your pip version and use the build option.
Handling an exception request
An exception needs a service name, the constraint it conflicts with, the reason, and an expiry. Approve it by adding a service level override rather than loosening the shared file. That way the exception stays visible and ends on its own.
Quick check
Does a constraints file install packages?
No. The pip documentation says including a package in a constraints file does not trigger its installation. It only limits the versions that can be installed.
Can one constraints file serve many projects?
Yes. The file can live in a central location, and the documentation says it can be served from a URL. That makes ownership and review important.
Sources
Last reviewed: 19 October 2026.
