Skip to content

fix: switch to python-discovery#2196

Merged
cjames23 merged 3 commits into
pypa:masterfrom
flying-sheep:python-discovery
Feb 26, 2026
Merged

fix: switch to python-discovery#2196
cjames23 merged 3 commits into
pypa:masterfrom
flying-sheep:python-discovery

Conversation

@flying-sheep

Copy link
Copy Markdown
Member

Fixes #2193 using public APIs only

@icfly2

icfly2 commented Feb 26, 2026

Copy link
Copy Markdown

the test failiures appear to be unrelated to the changes in the PR

@cjames23 cjames23 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for jumping on this!

@cjames23 cjames23 merged commit 49aa852 into pypa:master Feb 26, 2026
92 of 99 checks passed
@flying-sheep flying-sheep deleted the python-discovery branch February 26, 2026 16:37
@flying-sheep

Copy link
Copy Markdown
Member Author

np! btw, no idea why the “Allow edits and access to secrets by maintainers” was off, I actually really prefer when maintainers can edit my forks.

@jorng

jorng commented Feb 26, 2026

Copy link
Copy Markdown

Any chance we can get a rapid one-off release for this? It has broken a lot of CI pipelines, and it would be much easier if there was a release to resolve this, instead of having to pin a version of virtualenv in all projects using hatch.

Comment thread src/hatch/env/virtual.py
finally:
virtualenv_discovery.propose_interpreters = propose_interpreters
python_info = python_discovery.get_interpreter(
python_version, (), env=self.get_interpreter_resolver_env(), predicate=self._interpreter_is_compatible

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to @gaborbernat’s super fast response!

Sometimes all you have to do is ask. If you can think of any other monkey patching done in the code base, maybe it’s a good time to ask the relevant projects to add these respective features?

R7L208 added a commit to databrickslabs/tempo that referenced this pull request Mar 3, 2026
The lint-and-check CI job fails because virtualenv 21.0.0 removed the
propose_interpreters API that hatch 1.14.2 relies on. Hatch 1.16.5
(pypa/hatch#2196) fixes this by switching to the python-discovery package.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
tnixon pushed a commit to databrickslabs/tempo that referenced this pull request Mar 3, 2026
* Add test for show() k parameter to verify per-series row limiting

Adds test_show_k_2 which calls show(n=20, k=2) on a TSDF with 4 rows
per series, verifying that only the 2 most recent rows per series are
returned. This exercises the k parameter path that was previously only
tested for the error case (k > n).

Closes #326

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Upgrade hatch to 1.16.5 to fix virtualenv 21.0.0 incompatibility

The lint-and-check CI job fails because virtualenv 21.0.0 removed the
propose_interpreters API that hatch 1.14.2 relies on. Hatch 1.16.5
(pypa/hatch#2196) fixes this by switching to the python-discovery package.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Revert hatch 1.16.5, pin virtualenv<21 to fix Python 3.9 CI

Hatch 1.16.5 requires Python >=3.10, breaking CI for DBR 11.3/12.2
(Python 3.9). Revert to hatch 1.14.2 and pin virtualenv<21 to avoid
the removed API in virtualenv 21.0.0 (matching PR #454).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add missing test data entry for test_show_k_2

The test was failing in CI because the test_show_k_2 entry was missing
from tsdf_tests.json. Add the init data reference matching other
test_show_* tests.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
AAraKKe added a commit to DataDog/integrations-core that referenced this pull request Apr 29, 2026
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.
apurvagandhi pushed a commit to fidelity-contributions/datadog-integrations-core that referenced this pull request Apr 29, 2026
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Hatch does not work with virtualenv 21.0.0

5 participants