What does this PR do?

Switches the ddev hatch plugin to use uv as the installer for every hatch environment it collects (default, test, e2e, benchmark, latest, lint), and migrates the CI shared-dependency cache from pip's wheel cache to uv's wheel cache.

Motivation

ddev test is slow because pip spends a lot of time on metadata resolution even with wheels cached. Swapping pip for uv as the hatch installer makes environment setup substantially faster, both locally and in CI. uv was already partially used in the repo (resolve-build-deps.yaml, .gitlab/tagger/Dockerfile), so this rounds it out for the test path.

Core changes

• ddev/src/ddev/plugin/external/hatch/environment_collector.py
  • pip_install_command → uv_install_command (returns uv pip install)
  • finalize_config sets installer = 'uv' on every collected env (setdefault, so individual integrations can override back to pip if they ever need to)
  • get_initial_config sets the same on the lint env
  • pip added to lint env and test/e2e env deps (uv-managed venvs don't seed pip; mypy --install-types and a couple of in-env scripts still need it)
• ddev/pyproject.toml: bump hatch>=1.8.1 → hatch>=1.13.0 (first hatch version with the uv installer)
• datadog_checks_dev/pyproject.toml: bump virtualenv<20.22.0 → virtualenv>=20.26.1 in the [cli] extras. The old upper bound was added in 2023 to keep Py2 testing alive; core no longer tests Py2 and the cli extras already pull Py3-only tools, so the cap was dead weight blocking modern hatch.
• Four hatch.toml files migrated from python -m pip install to uv pip install in pre/post-install commands: ddev/hatch.toml, datadog_checks_dev/hatch.toml, root hatch.toml (docs env), kafka_consumer/hatch.toml.
• CI workflows now install uv via astral-sh/setup-uv and cache ~/.cache/uv:
  • .github/workflows/cache-shared-deps.yml
  • .github/workflows/test-target.yml
  • .github/workflows/test-fips-e2e.yml
  • .github/workflows/docs.yml
  • .github/workflows/build-ddev.yml
• Cache key prefix bumped v01-python-... → v02-uv-... so the new cache populates cleanly without colliding with the old pip cache.

No per-integration hatch.toml files needed touching beyond those four — the plugin injects installer = 'uv' into all envs collected via [env.collectors.datadog-checks].

Cache layout: why both uv AND pip paths are cached

The cache-shared-deps, test-target, test-fips-e2e workflows all cache two directories under a single key:

path: |
  ${{ runner.os == 'Windows' && '~\AppData\Local\uv\cache' || runner.os == 'macOS' && '~/Library/Caches/uv' || '~/.cache/uv' }}
  ${{ runner.os == 'Windows' && '~\AppData\Local\pip\Cache' || runner.os == 'macOS' && '~/Library/Caches/pip' || '~/.cache/pip' }}

Each line is a per-platform path (Linux / macOS / Windows) for one of the two wheel caches. Both directories are saved and restored together under one cache entry.

Why both:

• uv cache (~/.cache/uv) is what hatch envs and the system-level uv pip install --system write to. This is the cache that drives the speedup.
• pip cache (~/.cache/pip) is still used by the Python 2.7 branch in cache-shared-deps.yml (uv requires Py3.8+, so the Py2 step has to stay on pip). Without caching this path, the Py2 install step would re-download every wheel each run.

Caching both under one key with one actions/cache step keeps the workflow simple — single restore, single save, both ecosystems covered.

Snowflakes handled along the way

Switching the installer surfaced several second-order issues unrelated to uv itself but exposed by it. Documenting them so future debugging starts with context.

1. Windows venv cleanup blocked by uv hardlinks (_zstd.pyd lock)

Symptom: Windows minimum-base-package jobs failed during post-test cleanup with PermissionError: [WinError 5] Access is denied on backports/zstd/_zstd.cp313-win_amd64.pyd.

Cause: uv defaults to hardlink mode on Windows. When hatch>=1.13 (whose transitive backports-zstd ships a .pyd) is installed into a uv-managed venv, the .pyd is a hardlink to the uv cache. hatch env remove (invoked at the end of ddev test --compat, used by the minimum-base-package matrix) then can't shutil.rmtree the venv because the loaded extension keeps the file open, and Windows refuses to delete any hardlink to an open file. Whether this manifests on a given run depends on Defender activity / shell / Windows build — see the astral-sh/uv#7918 discussion.

Fix: Set UV_LINK_MODE=copy only on Windows minimum-base-package jobs in .github/workflows/test-target.yml. Regular Windows test jobs never run hatch env remove, so they keep the hardlink fast path. Refs: uv link-mode setting.

2. datadog-checks-tests-helper distribution name

Symptom: tests/cli/release/test_get_datadog_wheels.py::test_get_datadog_wheels failed in the ddev test job with the helper package now reported as datadog_checks_tests_helper (underscores) instead of datadog-checks-tests-helper (hyphens).

Cause: datadog_checks_tests_helper/setup.py had name='datadog_checks_tests_helper'. The legacy python setup.py bdist_wheel invocation that older pip+setuptools defaulted to silently normalized this to hyphens. Modern pip+setuptools (and uv) use the PEP 517 setuptools.build_meta:__legacy__ backend, which writes the literal name= value verbatim into METADATA. The virtualenv<20.22.0 bump alone (which brings modern pip+setuptools) would have broken this test even without the uv switch.

Fix: Change name='datadog_checks_tests_helper' → name='datadog-checks-tests-helper' in datadog_checks_tests_helper/setup.py. The package is now distributed under the same canonical hyphenated name on PyPI conventions.

3. SAP HANA application_name in audit logs

Symptom: sap_hana/tests/test_integration.py::test_check failed with the audit log carrying application_name='python3' while the test asserted 'python'.

Cause: The application_name field that the SAP HANA server records is the connecting client's process name (argv[0]//proc/self/comm on Linux). With installer = "uv" set on hatch envs, hatch ≥1.13 creates the venv via uv venv, whose canonical interpreter symlink is python3; the previous virtualenv-created venvs used python. So pytest is now launched as python3 and HANA records python3.

Fix: Update the three assertions in sap_hana/tests/test_integration.py from 'application_name': 'python' to 'application_name': 'python3' to reflect the new (and now stable) venv layout.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged