fix(deps): install the milvus-lite extra on Windows for Python >=3.10 (#3676)

[Anai-Guo]

Summary

Fixes #3676.

pip install -U "pymilvus[milvus-lite]" installs nothing on Windows, silently. The extra carries a sys_platform!='win32' marker:

milvus_lite = [
    "milvus-lite>=2.4.0;sys_platform!='win32'",
    ...
]

so the resolver drops the requirement, exits 0, and the user gets a pymilvus with no local mode — even though the README and docs list Windows as supported. There is no warning, because an extra whose markers all evaluate false is not an error.

Why the marker was right, and why it no longer is

It was correct when written. milvus-lite <3.0 published platform-specific wheels only:

milvus_lite-2.5.1-py3-none-macosx_10_9_x86_64.whl
milvus_lite-2.5.1-py3-none-macosx_11_0_arm64.whl
milvus_lite-2.5.1-py3-none-manylinux2014_aarch64.whl
milvus_lite-2.5.1-py3-none-manylinux2014_x86_64.whl

No Windows wheel existed, so excluding win32 was the only way to keep the extra resolvable.

Since 3.0 the project ships a single pure-Python wheel:

milvus_lite-3.2.0-py3-none-any.whl

py3-none-any installs on Windows. The exclusion is now stale.

Why a new marker instead of relaxing the existing one

milvus-lite 3.x declares requires_python >=3.10, while pymilvus still supports 3.9 (requires-python = '>=3.9'). Simply dropping !='win32' would let the resolver try to satisfy milvus-lite>=2.4.0 on Windows + Python 3.9, where no wheel exists for that platform.

Adding a separate win32 branch pinned to >=3.0 keeps each environment pointed at a distribution that actually exists:

platform	Python	resolved
win32	3.9	(nothing — correct, no candidate exists)
win32	3.10	milvus-lite>=3.0
win32	3.12	milvus-lite>=3.0
linux	3.9	milvus-lite>=2.4.0 (unchanged)
linux	3.12	milvus-lite>=2.4.0 (unchanged)
darwin	3.12	milvus-lite>=2.4.0 (unchanged)

Generated by evaluating the three requirement markers with packaging.markers.Marker(...).evaluate(env). Non-Windows resolution is byte-for-byte unchanged.

Verification

Milvus Lite was exercised end-to-end on Windows 11 (Python 3.12.10, clean venv), not just installed:

from pymilvus import MilvusClient
c = MilvusClient("wintest.db")
c.create_collection(collection_name="demo", dimension=4)
c.insert(collection_name="demo", data=[
    {"id": 1, "vector": [0.1, 0.2, 0.3, 0.4], "text": "hello"},
    {"id": 2, "vector": [0.9, 0.8, 0.7, 0.6], "text": "windows"},
])
print(c.search(collection_name="demo", data=[[0.1, 0.2, 0.3, 0.4]],
               limit=2, output_fields=["text"]))

milvus-lite 3.2.0
data: [[{'id': 1, 'distance': 1.0, 'entity': {'id': 1, 'text': 'hello'}},
        {'id': 2, 'distance': 0.8427009582519531, 'entity': {'id': 2, 'text': 'windows'}}]]
db file created: True

Collection creation, insert, and vector search all succeed, and the .db file is written.

Notes

This supersedes #3701, which proposed the same version-aware split and was closed by its author on 2026-08-12 without maintainer objection. I kept the >=3.10 gate for the reason given above and left the existing setuptools<82 pin untouched.

🤖 Generated with Claude Code

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Anai-Guo
To complete the pull request process, please assign longjiquan after the PR has been reviewed.
You can assign the PR to them by writing /assign @longjiquan in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[yhmo]

pyproject.toml line:84
Medium ---- This new win32 branch is not reflected in the committed uv.lock. At the PR head the lock still records the milvus_lite extra as milvus-lite>=2.4.0; sys_platform != 'win32' and extra == 'milvus-lite' (uv.lock requires-dist, ~line 3559) and keeps milvus-lite 3.0's resolution markers win32-excluded for Python 3.11-3.14 (uv.lock ~lines 2114-2124). Both CI workflows run uv sync --frozen, which uses the lockfile as the source of truth and does not check freshness, so the Windows branch of this extra will never be installed in the repo's own environments, and any uv lock / uv sync --locked run will report drift. The superseded PR #3701 regenerated uv.lock (adding the faiss-cpu win_amd64 wheel) when it changed this extra, and CONTRIBUTING.md documents uv.lock as the locked dependency graph used by uv. Please run uv lock and commit the updated lockfile in this PR.

[yhmo]

pyproject.toml line:84
Medium ---- tests/integration/lite/test_milvus_lite.py (unchanged by this PR) still hard-skips the whole module on Windows: pytestmark = pytest.mark.skipif(sys.platform.startswith("win"), reason="Milvus Lite is not supported on Windows"). That marker now directly contradicts the behavior this PR enables, so the fix is never exercised by the repo's own CI (the windows-2022 matrix collects then skips the Lite tests), and a future reader trusting the marker will keep believing Windows is unsupported. The issue discussion (#3676) explicitly proposed enabling these tests on a supported Windows/Python combination, and the superseded PR #3701 de-skipped the same file. Please re-gate the skip on python_version < '3.10' instead of the platform (milvus-lite 3.x requires Python >=3.10), and consider adding a CI step that installs .[milvus-lite] on Windows so this metadata fix is actually verified.

[Anai-Guo]

Thanks @yhmo — both points were correct and are fixed in 1d83032.

1. uv.lock was stale. Regenerated with uv lock (uv 0.9.x). The diff is +117/-65 and contains zero package version changes — it is entirely the mechanical consequence of the new marker: the python_full_version == '3.10.*' resolution marker splits into … and sys_platform != 'win32' / … == 'win32', and faiss-cpu gains its already-published win_amd64 / win_arm64 wheel entries. The two lines that matter now read:

{ name = "milvus-lite", marker = "python_full_version >= '3.10' and sys_platform == 'win32' and extra == 'milvus-lite'", specifier = ">=3.0" },
{ name = "milvus-lite", marker = "sys_platform != 'win32' and extra == 'milvus-lite'", specifier = ">=2.4.0" },

2. The module-level Windows skip contradicted the fix. Dropped the pytestmark = pytest.mark.skipif(sys.platform.startswith("win"), …) and the if not sys.platform.startswith("win") guard around it, leaving the plain pytest.importorskip("milvus_lite", …) to decide. That keeps Windows + Python 3.9 skipping (no installable candidate, as the pyproject comment explains) while letting 3.10+ actually run. import sys is now unused and removed.

Verified on real Windows, not by reasoning — this machine is Windows 11 / windows-2022-class:

$ uv run --group dev --extra milvus-lite python -c "import milvus_lite, platform, sys; print(...)"
milvus_lite 3.0 py 3.11.15 Windows

$ PYTHONPATH=. uv run --group dev --extra milvus-lite pytest tests/integration/lite -v
tests/integration/lite/test_milvus_lite.py::TestMilvusLite::test_milvus_client_with_local_db_path PASSED [ 25%]
tests/integration/lite/test_milvus_lite.py::TestMilvusLite::test_milvus_lite_insert_search        PASSED [ 50%]
tests/integration/lite/test_milvus_lite.py::TestMilvusLite::test_milvus_lite_multiple_clients_same_db PASSED [ 75%]
tests/integration/lite/test_milvus_lite.py::TestMilvusLite::test_illegal_name                     PASSED [100%]
============================== 4 passed in 4.48s ==============================

So the Lite server does start, serve, and answer on Windows under milvus-lite 3.0 — the four tests that CI has been collecting-then-skipping on the windows-2022 matrix leg now genuinely exercise the path this PR enables.

(The AllocTimestamp … Method not implemented! lines in the log are pre-existing and unrelated — milvus-lite does not implement that RPC and the client falls back; the same lines appear on Linux.)

🤖 Generated with Claude Code