What decides whether one all-in-one project manager should own every Python repository?

## Frame it as a portfolio decision The question is not "which manager is best" but "does one workflow fit the repositories we own, and what does it cost us to be wrong". A lead who answers with a tool name has skipped the analysis. Start by classifying what exists: - **Applications and services** — publish nothing, commit a lock, want a reproducible deploy. These benefit most; the manager's whole model is built for them. - **Libraries** — publish a distribution, must declare abstract ranges, and gain much less because their consumers never see the lock. They still want the metadata and the environment management. - **Research, notebooks and data work** — often need non-Python binaries and platform-specific builds, and are frequently served by a solver that manages more than Python distributions. A pure-Python manager may simply not resolve their stack. - **Scripts, infra and monorepo leaves** — no distribution at all. Dependency groups cover them; extras never could. If three of those four categories are well served and the fourth is not, you do not have a single-tool decision. You have a decision about which tool is the *default* and what the documented exception is. ## The axes that actually decide it **Onboarding and contributor mix.** One command to a working checkout is a real, repeated saving, and it is largest where people move between repositories or join often. It is smallest where contributors are external and already have their own habits — an open-source library that mandates an unusual tool loses drive-by contributions. **CI cost.** Every job now installs the manager and then resolves or syncs. Measure it. A fast manager with a warm shared cache can be dramatically cheaper than the pip baseline; a slow one on cold runners is a tax paid on every pipeline, every day. **Index and authentication.** Most organisations install from an internal mirror or a private index with its own authentication. Whether the manager supports that cleanly — credentials, extra indexes, index priority, offline mirrors — is frequently the constraint that decides the answer, and it is the one most often discovered after the mandate. **Security and provenance.** A single lock format across the estate makes hash verification, vulnerability scanning and bill-of-materials generation one integration instead of five. That is a genuine argument for standardizing, and it usually outweighs developer preference. **Exit cost.** Ask concretely: if this tool were abandoned, or changed licence, or broke on the next interpreter release, what would migration cost? If the answer is "regenerate a lock and rewrite some CI", the bet is small. If half the workflow lives in tool-specific configuration and plugins, it is not. ## Standardize the interface, not the vendor The move that makes the whole question cheaper is to be deliberate about what is standard and what is vendor-specific. Standard, and portable by construction: the `[project]` table (PEP 621), dependency groups (PEP 735), abstract ranges in the declaration, a committed lock for applications, and a small fixed set of task names — set up, test, lint, build — that every repository exposes however it likes. CI and documentation target *those names*, not the manager's commands. Vendor-specific, and to be kept thin: everything under the tool's own configuration table, its plugins, and any workflow that only that tool can express. The thinner that layer, the more the choice is reversible. This also makes migration incremental. Because the declaration is standard, you can move repositories one at a time and the ones that have not moved are still readable by dependency bots, scanners and audit scripts that have never heard of your manager. ## The operational conditions to attach If you do standardize, attach three conditions or you have not finished the job. **Pin the manager.** An installer that auto-updates is an unpinned build input; a release can change resolution behaviour and change your builds with no commit. Pin it in CI images and treat upgrades as reviewed changes. **One install path per repository.** Development, CI and production must all install from the same artifact with the same tool. Two paths means reproducibility becomes something you verify rather than something you have. **Write down the exception.** Name which category of repository is exempt and what it uses instead. An undocumented exception becomes a second de facto standard that nobody owns. ## The honest answer Standardize when the repositories are homogeneous enough that one workflow genuinely fits, when the tool clears your index and authentication constraints, and when the exit is a week. Do not standardize when the estate is genuinely heterogeneous, when a large share of contributors are external, or when the workflow would end up living in vendor-specific configuration. In either case, the durable investment is the standard declaration underneath — that survives whichever way the decision goes, and it is what makes the decision revisitable in two years.