Enterprise-Quality Python Development Practices

Full report

On this page

Executive summary

Enterprise Python succeeds when teams treat Python as a socio-technical platform, not just a language. The stable pattern across primary sources is consistent: standardize style and packaging in pyproject.toml; use type hints with gradual-but-enforced type checking; prefer a modular monolith or layered package structure until there is clear organizational and operational need for microservices; invest in a test portfolio dominated by fast unit and service-level tests, with contract, property-based, and fuzz testing added where they buy down integration and edge-case risk; automate quality and security gates in CI; produce immutable artifacts such as wheels and container images; make environments reproducible with lockfiles and hashes; and run production systems with first-class observability, SLOs, and rollback paths.

For most organizations, the highest-leverage default stack in 2026 is: pyproject.toml as the single configuration hub; Ruff for linting and often formatting; Black if the organization prefers a stable dedicated formatter; mypy or Pyright for static typing; pytest plus fixtures for mainstream testing; Hypothesis for property-based tests in core logic and parsers; Pact for contract tests when services evolve independently; pip-tools, Poetry, uv, or Conda depending on the environment model required; wheels for internal distribution; private artifact repositories instead of ad hoc direct installs; Docker multi-stage builds for deployable services; OpenTelemetry plus Prometheus-compatible metrics for observability; and a combination of SCA, secrets scanning, SAST, and DAST for security controls.

Two strategic trade-offs matter most. First, standardization versus flexibility: enterprise platforms benefit from fewer choices, even if some individual teams would choose differently. Second, speed versus coordination: microservices, canary releases, strong SLO policies, and deep security scanning all improve risk control, but each adds operational overhead. The strongest guidance from architecture and delivery sources is therefore conservative: push complexity to the point where it is justified by scale, team topology, or risk, and no sooner.

Python’s current ecosystem strength also matters for enterprise planning. GitHub’s 2024 Octoverse reported Python overtaking JavaScript as the most popular language on GitHub, and the 2025 Python Developers Survey highlighted both broad Python use and a large installed base still running older Python versions. That combination means enterprises should plan for Python as a durable strategic platform, but also budget for runtime upgrades, dependency modernization, and tooling consolidation.

Coding standards and architecture

Enterprise coding standards should converge on three layers: language conventions, automated enforcement, and project-local exceptions. PEP 8 remains the base style reference, but it explicitly allows project-specific standards where needed. Type hints are not runtime-enforced by Python itself, which is why enterprises need a distinct static analysis step. The practical result is a style policy such as: PEP 8 in spirit, mandatory formatting, mandatory import ordering, mandatory linting, mandatory docstring conventions for public APIs, and mandatory type checking for critical packages with gradual rollout elsewhere.

Ruff and Black represent two viable standardization models. Black is optimized for stable, low-debate formatting and explicitly aims to reduce diff noise and make review easier. Ruff’s value proposition is consolidation: one fast interface that can cover linting, import sorting, and formatting that would otherwise require several tools. The trade-off is governance, not capability. Black is the safest choice when an organization wants a narrowly-scoped formatter with few knobs. Ruff is the stronger choice when the organization wants a converged velocity stack and is comfortable adopting a broader tool surface from one vendor. If a team still uses isort with Black, official isort guidance is to enable the black profile to avoid formatter conflicts.

Type checking should be gradual, directory-scoped, and policy-driven. mypy explicitly supports gradual typing, which is why it remains well suited to legacy codebases. Pyright adds fast analysis and fine-grained configuration, including scoped strictness, execution environments, and pyproject.toml support. In practice, enterprise teams usually succeed with a ratchet model: start by type-checking newly created or high-value modules in strict mode, then expand strict coverage outward rather than attempting “strict everywhere” on day one.

Architecture should usually begin with a layered modular monolith, not microservices. Azure’s architecture guidance describes traditional N-tier systems as clear and migration-friendly but less agile when horizontal layering spreads changes across multiple parts of the system. Fowler’s “Monolith First” argument is more direct: successful microservice stories often start with a monolith, while greenfield microservices frequently incur a “microservice premium” before boundaries are understood. The common enterprise pattern that follows is: modular monolith first, explicit domain boundaries second, selective extraction to services only when deployment independence, team autonomy, or scaling characteristics clearly justify it.

flowchart LR
    subgraph Modular_monolith
        UI[API / UI Layer]
        APP[Application Services]
        DOM[Domain Modules]
        INFRA[Infrastructure Adapters]
        DB[(Shared Database)]
        UI --> APP --> DOM --> INFRA --> DB
        APP --> DOM
    end

    subgraph Microservices
        GW[API Gateway]
        S1[Service A]
        S2[Service B]
        S3[Service C]
        E1[(DB A)]
        E2[(DB B)]
        E3[(DB C)]
        GW --> S1 --> E1
        GW --> S2 --> E2
        GW --> S3 --> E3
        S1 -. events / contracts .-> S2
        S2 -. events / contracts .-> S3
    end

A packaging-aware source layout is part of architecture, not just packaging trivia. PyPA’s guidance notes that src/ layout helps prevent accidental imports from the working directory and makes packaging mistakes easier to detect. For enterprise codebases with multiple contributors and CI runners, that is usually worth the additional editable-install step.

Example baseline pyproject.toml

[build-system]
requires = ["hatchling>=1.26"]
build-backend = "hatchling.build"

[project]
name = "acme-payments"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
  "pydantic>=2.8,<3",
  "httpx>=0.27,<1",
]

[tool.ruff]
line-length = 100
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "I", "B", "UP", "N", "S"]
ignore = ["E501"]

[tool.mypy]
python_version = "3.12"
warn_unused_ignores = true
warn_redundant_casts = true
disallow_untyped_defs = true
no_implicit_optional = true

[tool.pyright]
include = ["src", "tests"]
strict = ["src/acme_payments/domain", "src/acme_payments/contracts"]

[tool.pytest.ini_options]
testpaths = ["tests"]
addopts = "-q --strict-markers"

This configuration follows PyPA’s recommendation to centralize build metadata in pyproject.toml, uses Ruff’s official configuration surface, and uses tool-native sections for mypy and Pyright.

Implementation checklist

• Adopt one canonical formatter and one canonical lint policy; allow exceptions only through documented suppressions, not local preference.
• Put build metadata and tool configuration in pyproject.toml; avoid fragmented config unless a tool does not support it.
• Use src/ layout for shared libraries and regulated or business-critical services.
• Define a type-checking ratchet: strict for new modules, directory-scoped strictness for high-value domains, and measured burn-down for legacy code.
• Start with a modular monolith unless you can name a concrete service-boundary, ownership, deployment, or scaling problem that services solve better.

Testing strategy

A mature Python testing strategy is intentionally asymmetric: many small unit tests, fewer integration tests, and a carefully selected set of broad-stack or end-to-end tests. Fowler’s test pyramid remains the clearest description of that balance, and pytest’s own documentation emphasizes that the framework scales from small readable tests to more complex functional testing. In enterprise Python, the practical implication is to make the default test easy to write, fast to run locally, and deterministic in CI.

pytest is usually the right default because its fixtures are explicitly designed to be modular and scalable. That matters in enterprise code because fixtures are not just test utilities; they are the primary control surface for dependency injection, controlled test state, and environment shaping. A common failure mode in large repos is fixture sprawl, where fixtures become hidden global state. The countermeasure is simple: keep fixtures near the tests that use them unless they are intentionally cross-cutting, and name them after the capability they provide, not the implementation detail they wrap.

Unit and integration tests should be augmented, not replaced, by property-based testing. Hypothesis explicitly presents property-based testing as a powerful addition to unit testing rather than a universal replacement. In enterprise systems, it pays off disproportionately well around serializers, parsers, financial calculations, query builders, idempotency logic, permission matrices, and data transformations. The strongest teams do not use it everywhere; they use it where “example-by-example” testing leaves too many edge conditions unexplored.

Contract testing becomes strategically important once services evolve independently. Pact defines contract testing as validating integration points in isolation against a shared contract and positions it as an alternative to expensive and brittle integration tests. This is especially valuable when Python services interact with front ends, partner APIs, or mixed-language service meshes. Schema validation alone is not enough when compatibility depends on concrete request-response interactions and backward evolution discipline.

Fuzzing and schema-driven generative testing should be concentrated where failure is expensive or inputs are adversarial. Google’s Atheris provides coverage-guided fuzzing for Python and native extensions, while Schemathesis generates property-based tests directly from OpenAPI or GraphQL schemas and is built to find server errors and edge cases that manual examples miss. For most enterprise teams, that means using fuzzing on parsers, protocol handlers, and security-sensitive input paths, and using schema-driven testing on public and internal APIs.

Test data should be treated as production-style assets. pytest fixtures make it easy to define stable “known good” database state, files, or event payloads, but teams should resist large golden datasets with unclear provenance. The best enterprise pattern is layered test data: lightweight factories for unit tests, realistic but small curated fixtures for integration tests, and contract fixtures that are versioned with the consumer or producer they represent.

Example unit-plus-property test

from hypothesis import given, strategies as st

def normalize_account_id(raw: str) -> str:
    return raw.strip().replace("-", "").upper()

@given(st.text())
def test_normalize_is_idempotent(value: str) -> None:
    once = normalize_account_id(value)
    twice = normalize_account_id(once)
    assert once == twice

This kind of test is a good fit for round-trip or idempotency properties, which Hypothesis explicitly recommends as strong entry points.

Implementation checklist

• Make pytest the default test runner and fixture system for application and library code.
• Enforce a test pyramid: broad unit coverage, targeted integration coverage, minimal UI or broad-stack tests.
• Add property-based tests for core invariants, transformations, and protocol logic.
• Add contract tests for independently deployed services or clients.
• Add fuzzing or schema-driven generative tests on adversarial-input paths and public APIs.
• Version test data and fixtures with the domain contract they support; keep fixtures explicit and local by default.

CI, CD, release management, and distribution

A good Python delivery pipeline turns source into immutable evidence: tested commits, signed or otherwise auditable artifacts, deployable images, and a rollback path. GitHub Actions’ documentation is explicit that the platform is meant to build, test, and deploy pipelines, and its Python guide covers build, test, artifact packaging, and PyPI publishing. The enterprise lesson is not “use GitHub Actions specifically”; it is that the pipeline should treat Python as an artifact-producing system, not just a script runtime.

Branching strategy should optimize for integration frequency and change visibility. Trunk-based development’s central claim is that frequent integration into trunk is a key enabler of continuous integration and continuous delivery. GitHub Flow is likewise a lightweight, short-lived branch model suited to frequent deployment. In practice, enterprise Python teams usually do best with one of two models: trunk-based delivery for services and internal applications that ship continuously, or a trunk-plus-release-branch model for products that need supported release lines. Heavy long-lived branching should be treated as an exception because it delays integration and raises merge risk.

Semantic Versioning is still the least-worst default when a Python package or service has a meaningful public API. The crucial requirement in the specification is that version increments communicate API compatibility. For internal-only systems without an explicit API, teams often misuse SemVer as ceremony. The fix is to define the contract first: package API, HTTP contract, event schema, CLI interface, or data contract. Then version the contract.

Release strategies should match blast radius and operational maturity. AWS guidance on blue-green deployments emphasizes validation on the green environment and fast rollback by shifting traffic back to blue. AWS CodeDeploy also documents predefined canary and linear traffic-shifting options for ECS and Lambda. Kubernetes exposes direct rollout undo support. The analytical takeaway is straightforward: use rolling or all-at-once only where rollback is cheap; use canary when you need progressive exposure and strong telemetry; use blue-green when you need the fastest clean rollback and can afford parallel environments.

Python packaging and distribution should prefer wheels over source distributions for most enterprise consumption. The wheel specification defines .whl as the binary distribution format, and PyPA guidance notes that wheels install substantially faster than source distributions. Build wheels in CI, store them in an internal package repository, and deploy from those artifacts rather than rebuilding source at deploy time. If the deployment unit is a container, the image should still be built from versioned Python artifacts, not from mutable checkout state.

Private package distribution should use a real package repository, not ad hoc file shares or unaudited direct VCS installs. AWS CodeArtifact documents a supported path for Python via pip and twine, and pip’s own docs warn that --extra-index-url is unsafe because of dependency confusion. The secure pattern is either a private primary index or a repository manager that proxies and governs upstreams, not a casual “add an extra index” workflow.

Docker’s official best practices map cleanly to Python services: use multi-stage builds, choose a trusted and preferably small base image, rebuild frequently, use .dockerignore, pin base image versions, and build/test images in CI. Docker’s Python guide also explicitly frames containerization as a way to package code, dependencies, configuration, and runtime into a portable unit that behaves consistently across laptop, CI runner, and production.

flowchart LR
    A[Commit / PR] --> B[Pre-commit hooks]
    B --> C[CI: lint + type check + unit tests]
    C --> D[CI: integration + contract + security scans]
    D --> E[Build wheel]
    E --> F[Build container image]
    F --> G[Publish to internal registry]
    G --> H[Deploy to staging]
    H --> I[Smoke tests + canary analysis]
    I --> J{SLO / health pass?}
    J -->|Yes| K[Progressive production rollout]
    J -->|No| L[Rollback / rollout undo]

Example CI workflow

name: ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.12", "3.13"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: python -m pip install -U pip
      - run: python -m pip install -r requirements-dev.txt
      - run: ruff check .
      - run: mypy src
      - run: pytest -q --maxfail=1 --disable-warnings

  build:
    needs: quality
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python -m pip install build
      - run: python -m build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/*

This follows GitHub’s official pattern for building and testing Python while adding enterprise-quality stages for lint and type-check gates.

Implementation checklist

• Use short-lived branches with required reviews and required status checks on protected branches.
• Publish versioned wheels from CI and store them in an internal artifact repository.
• Treat containers as deployment artifacts built from tested source and pinned base images.
• Use SemVer only after you define the public contract being versioned.
• Prefer canary or blue-green releases for user-facing or high-value services, and keep rollback commands automated and rehearsed.

Dependency, environment, and security compliance

Environment isolation is table stakes. Python’s standard venv module creates isolated environments and is explicitly documented as the standard tool for this purpose, while virtualenv remains the more feature-rich third-party alternative. In enterprise practice, venv is the simplest default for applications and CI, while virtualenv is useful when organizations need its extended environment management features or compatibility behaviors.

Reproducibility requires more than pinned top-level dependencies. pip’s official guidance on repeatable installs distinguishes degrees of repeatability, and its secure installs guidance is blunt: default pip install does not protect against remote tampering unless you add measures such as hash-checking mode and binary-only installs. pip-tools exists precisely to compile and sync deterministic dependency sets, while Poetry’s sync command ensures that only locked dependencies are present. Conda’s current docs likewise emphasize lockfiles as exact environment captures, and PyPA has now standardized pylock.toml for reproducible environments, though pip support is still marked experimental. The strategic conclusion is that enterprises should require lockfiles for releaseable applications and should treat unhashed, solver-at-install-time production builds as a policy exception.

Tool choice here depends on the environment model. pip plus venv is the simplest path and remains the packaging ecosystem baseline. pip-tools is strong when the organization wants to stay close to PyPA standards while gaining deterministic lock outputs. Poetry is strong when teams want integrated dependency management and packaging in one opinionated tool. Conda is strongest where Python is only part of the environment and native or scientific dependencies dominate. uv is increasingly attractive when organizations want a single fast tool that spans environment creation, locking, tool execution, Python installation, and a pip-compatible interface, but it is still newer than the long-established PyPA stack and should usually be introduced behind a platform-team standard rather than by unmanaged bottom-up spread.

Supply-chain security should be built into dependency workflows, not appended later. OWASP’s software supply chain guidance explicitly frames modern development as a chain of creation, transformation, and assessment steps that must be secured with automation. OpenSSF Scorecard is useful for evaluating the security posture of dependencies and upstream projects. Sigstore provides signing and verification for artifacts, including container images and SBOMs, with auditable signing events. pip-audit scans Python environments and requirement sets against known vulnerabilities from PyPA’s advisory data. GitHub Dependabot and dependency review shift some of this left by opening security-update pull requests and blocking vulnerable new dependencies in PRs.

Secrets management is a separate control plane. OWASP’s secrets guidance recommends central storage, provisioning, auditing, rotation, and lifecycle management. The rule for enterprise Python should therefore be unambiguous: no long-lived secrets in source control, no secrets in container images, no human-managed production credentials where workload identity or vault-based short-lived credentials are possible. GitHub secret scanning is an effective backstop, but it is not a substitute for a secrets platform.

SAST and DAST should be layered. Bandit gives Python-specific AST-based security scanning, CodeQL provides broader code scanning with Python query suites and pack customization, and OWASP ZAP remains a practical open-source DAST option for running applications and APIs. Enterprises with deeper AppSec programs may also standardize on Semgrep or commercial platforms, but the minimum mature baseline is SCA plus Python-aware SAST plus at least targeted DAST against externally reachable services.

License compliance should be formalized in the same lane as dependency review. SPDX provides standardized license identifiers and is an ISO standard for SBOM-related use cases. GitHub’s dependency review action can also fail pull requests based on license policy. The combination is powerful: standardize SPDX identifiers in metadata and SBOMs, then enforce allowed and denied licenses at PR time.

Example reproducible install policy

1. Resolve dependencies from a locked source in CI.
2. Enforce hashes for production installs when using pip requirements.
3. Use a private package index as the primary source for internal packages.
4. Scan lockfiles and built environments for vulnerabilities.
5. Generate and archive an SBOM for each release artifact.

That policy is consistent with pip’s repeatable and secure install guidance, PyPA lockfile work, and modern software supply-chain controls.

Implementation checklist

• Standardize on one environment model per platform type: app/service, data science, or mixed native environment.
• Require lockfiles for deployable applications and enforce sync-only installs in CI.
• Avoid --extra-index-url for private packages; use a governed private repository or primary index instead.
• Run SCA, secret scanning, SAST, and dependency review on every PR; run DAST on staging or ephemeral environments.
• Generate SBOMs and attach license policy to dependency governance.

Performance, scalability, observability, and operations

Python performance work should start with measurement, not folklore. The standard library’s asyncio documentation defines the event loop as the core of async applications for tasks, callbacks, network I/O, and subprocesses, which is why asyncio is fundamentally an I/O-concurrency tool rather than a universal speed tool. For profiling, built-in profilers are useful in development, but sampling profilers such as py-spy are especially valuable in production because they can observe running processes with low overhead and without restarts. Scalene adds unusually fine-grained CPU and memory profiling and can accelerate root-cause analysis in hot services or batch jobs.

Caching should be explicit and bounded by correctness. Python’s functools.cache and lru_cache provide lightweight function-level memoization, and the docs explicitly note the performance advantage of the unbounded cache form. In enterprise systems, that is useful but only for pure or effectively pure functions. For service architectures, the real challenge is usually cache invalidation, key design, and staleness tolerance. The safe rule is to treat cache policy as part of the domain contract and observe it with metrics, not as a hidden micro-optimization.

Scalability decisions should map to workload shape. For request/response services with high I/O wait, async architectures can reduce per-request overhead and increase concurrency. For CPU-heavy work, enterprises typically need process-level parallelism, queue-based work partitioning, or native accelerators. The critical trade-off is operational simplicity: async adds cognitive overhead in exchange for better I/O scalability; process and distributed concurrency add deployment and debugging complexity. That is one more reason to profile first and to isolate hot paths behind clear interfaces.

Observability should be standardized around correlated logs, metrics, and traces. OpenTelemetry positions itself as a vendor-neutral framework for generating and exporting all three telemetry signals and notes support from more than 90 observability vendors. The strongest enterprise pattern is therefore instrumentation to OTel semantic conventions, export through an OTel collector or compatible path, and backend choice decoupled from application code. Prometheus guidance complements this by recommending that instrumentation be integral to the code and sufficiently broad to expose service health at every library, subsystem, and service layer.

SLOs and error budgets are what turn telemetry into operating policy. Google’s SRE guidance defines an SLO as a target measured by an SLI, while the example error-budget policy shows how change can be halted when the budget is exhausted. The broader case studies from Evernote and The Home Depot show that SLO culture scales beyond Google and can materially improve prioritization and reliability alignment in large enterprises. For Python services, that means release policy should be explicitly tied to reliability objectives rather than run on intuition or incident severity alone.

Example OpenTelemetry bootstrap

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider

resource = Resource.create({
    "service.name": "payments-api",
    "service.namespace": "billing"
})

trace.set_tracer_provider(TracerProvider(resource=resource))
tracer = trace.get_tracer(__name__)

This reflects OpenTelemetry’s Python instrumentation model and aligns with the service-resource semantic conventions that make telemetry portable across tools.

Implementation checklist

• Make profiling a release-readiness activity for hot services, jobs, and new high-scale features.
• Use async for I/O-heavy paths, not as a reflex for all Python services.
• Instrument logs, metrics, and traces with OpenTelemetry and use consistent service identifiers.
• Define SLOs for user-visible services and attach rollout policy to error-budget status.
• Expose cache behavior, queue depth, latency, and dependency errors as first-class metrics.

Developer workflows, governance, and tool comparison

Developer experience is a control surface for quality. pre-commit exists specifically to solve cross-language hook management and to make local enforcement reproducible without custom machine setup. GitHub’s pull request reviews and branch protection rules provide the collaboration and policy mechanisms to require approvals and passing checks. In practice, the enterprise sweet spot is simple: developers should get the same checks locally that CI will run remotely, and merges should be impossible when required checks or required approvals are missing.

IDE choice is best standardized as “supported, not mandated,” unless compliance requirements or a heavily curated platform justify stronger control. PyCharm’s inspection model is deeply suited to Python-heavy teams that want strong project-wide static analysis and refactoring. VS Code’s Python extension provides linting, testing, and debugging integrations that are often sufficient, especially in polyglot organizations. The practical enterprise pattern is to standardize on tool outputs and project config, not on a single editor, unless training and support economics argue otherwise.

Governance should be lightweight but formal. Diátaxis provides a durable documentation model around tutorials, how-to guides, explanation, and reference. ADRs are valuable because they centralize reasoning, architectural change history, and newcomer context. Enterprises that scale well usually pair these with repository templates, service templates, baseline pyproject.toml files, sample CI workflows, and a short platform cookbook for common deployment and security decisions.

The comparison matrix below is a synthesized assessment. “Maturity” and “enterprise adoption signal” are qualitative ratings based on ecosystem age, standards alignment, official documentation, integration breadth, and large-ecosystem signals rather than vendor-reported install counts.

This table reflects the strongest enterprise defaults: start with modular monoliths, adopt a converged style and typing toolchain, make pytest the default, choose a lockfile strategy intentionally, and standardize observability and supply-chain controls across repos.

A pragmatic enterprise rollout usually works best in phases. First, standardize style, lint, typing, tests, packaging layout, and branch protection. Second, make builds reproducible and secure with lockfiles, hashes where appropriate, private repositories, and dependency security automation. Third, instrument production, attach rollouts to health and SLOs, and add progressive delivery. Fourth, introduce advanced testing and service decomposition only where data shows need.

Implementation checklist

• Ship repository templates with pyproject.toml, pre-commit config, CI workflow, Dockerfile, and test skeletons.
• Require PR reviews and protected branches for all shared repos.
• Publish ADRs for architecture, security, and platform deviations.
• Organize docs using a consistent framework such as Diátaxis.
• Support at least one “full Python IDE” and one “polyglot editor” path, but standardize project config rather than editor preference.

Open questions and limitations

This report prioritizes official documentation, original specifications, major vendor architecture guidance, and well-known industry references. Where the market lacks strong neutral primary sources, some judgments—especially the qualitative “maturity” and “enterprise adoption signal” ratings in the comparison table—are synthesized assessments rather than vendor-published metrics. They are supported by ecosystem age, standards alignment, integration breadth, and developer ecosystem signals, but they are still evaluative rather than canonical facts.

The Python packaging landscape is also evolving quickly. In particular, pylock.toml is now standardized by PyPA, but pip’s support is still marked experimental, so organizations should treat it as an important direction of travel rather than a universally ready enterprise baseline today. Likewise, uv is strategically interesting and increasingly capable, but many enterprises will still want a staged adoption plan rather than immediate replacement of established PyPA-centric workflows.