Pin to specific versions for deterministic builds and stable cache reuse.
virtualenv stays on the 20.x line (latest 20.39.1) due to hatch issue #2193.

…23497)

* Use uv as hatch installer for faster test environment setup

- ddev hatch plugin: set installer = 'uv' on every collected env (default,
  test, e2e, benchmark, latest, lint) and switch _dd-install-packages
  scripts to 'uv pip install'.
- Bump min hatch dependency to >=1.13 (first version with the uv installer).
- CI: add astral-sh/setup-uv and migrate the shared dependency cache from
  ~/.cache/pip to ~/.cache/uv (plus pip path for the Py2 branch). Workflows
  updated: cache-shared-deps, test-target, test-fips-e2e, docs, build-ddev.

* Bump virtualenv min in datadog-checks-dev[cli] to unblock hatch>=1.13

Modern hatch (1.10+, where the uv installer lives) requires
virtualenv>=20.26.1, but datadog_checks_dev[cli] was capping it at
<20.22.0 — a constraint added in 2023 to keep Py2 testing alive. Core
no longer tests Py2, and the [cli] extras already pull tools that don't
support Py2 anyway, so the upper bound was dead weight.

Also adds changelog entries for both packages.

* Add pip to uv-managed envs and switch hatch.toml pip calls to uv

uv-managed venvs don't seed pip the way virtualenv does. This breaks two
classes of in-env consumers:

- mypy --install-types in lint envs (auto-installs missing type stubs)
- python -m pip subprocess calls in tests / hatch.toml pre/post-install
  commands

Fixes:

- Add pip to lint env deps (for mypy) and to test/e2e env deps
  (defensively, for any test that subprocesses pip).
- Migrate the four hatch.toml files that explicitly used python -m pip
  (ddev, datadog_checks_dev, root docs env, kafka_consumer) to uv pip.

* Use canonical hyphenated distribution name for datadog-checks-tests-helper

uv builds this legacy setup.py-only package via setuptools.build_meta:__legacy__,
which writes the name verbatim into METADATA. With the underscored form
'datadog_checks_tests_helper', get_datadog_wheels() in datadog_checks_base
(filters by 'datadog-' prefix) didn't pick it up, breaking
test_get_datadog_wheels. Distribution names should use hyphens per PEP 503/625
anyway.

* Set UV_LINK_MODE=copy on Windows to allow venv cleanup

uv defaults to hardlink mode on Windows. When backports.zstd._zstd.pyd
(transitive of hatch>=1.13) is loaded by Python during the test run,
Windows refuses to delete the venv's hardlinked copy while the cache
copy is still pinned. This breaks hatch env remove invoked by
ddev test --compat / --recreate.

See astral-sh/uv#7918

* Scope UV_LINK_MODE=copy to Windows minimum-base-package only

Regular Windows test jobs do not invoke 'hatch env remove' at the end,
so they keep uv's hardlink speed-up. Only minimum-base-package jobs
(which run with --compat) need the copy mode to allow venv cleanup.

* Make sap_hana audit log test tolerant of venv binary name

The application_name field in HANA audit logs reflects the client
process name (argv[0]). uv-created venvs launch pytest as 'python3',
virtualenv-created venvs launch it as 'python'. Both are valid; the
integration just forwards whatever HANA reports. Use ANY instead of
asserting on the runner's binary name.

* Pin sap_hana audit log application_name to python3

uv-created venvs (which is what hatch>=1.13 uses with installer=uv)
launch pytest as python3, so HANA records the audit-log
application_name as python3 rather than python. Update the test to
match the new stable layout.

* Pin hatch and virtualenv in build-ddev workflow

Pin to specific versions for deterministic builds and stable cache reuse.
virtualenv stays on the 20.x line (latest 20.39.1) due to hatch issue DataDog#2193.

* Pin virtualenv to 21.3.0 to match hatch 1.16.5 requirements

hatch 1.16.5 declares virtualenv>=21 as a hard requirement (the
2026-02-25 virtualenv 21.0.0 release moved interpreter discovery to
the python-discovery package, fixed in hatch by pypa/hatch#2196).
The earlier 20.39.1 pin would have failed dependency resolution.