# Single-env pins for unsloth + studio + data-designer
# MiniMax-H3's merged Diffusers workflow needs the current Hugging Face stack.
transformers==5.5.0; python_version >= "3.10"
transformers==4.57.6; python_version < "3.10"
# The window both transformers pins above declare and enforce at import. Redundant
# while they are pinned, and kept for the same reason as the anyio cap below: a
# global cap is what stops a later with-deps step, or a future relaxation of the
# transformers pin, from pairing them with a tokenizers transformers rejects.
tokenizers>=0.22.0,<=0.23.0
trl==0.23.1
huggingface-hub>=1.23.0,<2.0; python_version >= "3.10"
huggingface-hub==0.36.2; python_version < "3.10"

# Unsloth stack
datasets==4.3.0
# pyarrow has never published a win_arm64 wheel (apache/arrow#48539). The floor below is the
# floor of the wheels install.ps1 stages, not of anything upstream ships.
pyarrow==23.0.1; sys_platform != "win32" or platform_machine != "ARM64"
pyarrow>=21.0.0; sys_platform == "win32" and platform_machine == "ARM64"

# FastMCP compat
fastmcp>=3.0.2
mcp>=1.24,<2
websockets>=15.0.1

# Cap anyio <4.14: 4.14's new asyncio per-task cancel scope (TaskHandle/_run_coro)
# gets exited in the wrong task on Python 3.13 under starlette's collapsing task
# group, raising "RuntimeError: ... exit a cancel scope that isn't the current
# task's" on streaming responses (#6483); 4.13 has no such code. Global cap so
# later with-deps steps can't re-resolve it up.
anyio<4.14.0

# accelerate 1.15.0 calls model_has_dtensor() unconditionally in prepare_model, reaching
# torch._C._distributed_c10d, which AMD's Windows ROCm wheels do not ship, so every run dies
# at trainer start (huggingface/accelerate#4249). A marker cannot say "ROCm", so this caps
# Windows generally; CUDA there loses only 1.15's DTensor placement fix. Lift once upstream
# guards the call. install_python_stack.py repairs an install that is already past the cap.
accelerate<1.15.0; sys_platform == "win32"

# pandas publishes win_arm64 wheels from 3.0 only; 2.3.x would source-build there.
pandas==2.3.3; sys_platform != "win32" or platform_machine != "ARM64" or python_version < "3.11"
pandas>=3.0,<4; sys_platform == "win32" and platform_machine == "ARM64" and python_version >= "3.11"

# av (PyAV) 16+ builds its macOS arm64 wheels against macosx_14_0, so on macOS 13 none
# are installable and the resolver falls back to a source build, which needs FFmpeg
# headers the Xcode CLT do not supply and so fails however that Mac is equipped.
# 15.1.0 is the newest release with a macosx_13_0 arm64 wheel; 17+ moves to cp311-abi3
# at macosx_14_0 too.
#
# The remaining sdist-only macOS defaults are pure Python, hence allowlisted in
# .github/scripts/clean-machine-assert.sh instead; cryptography below is the one
# other package that would compile.
av<16; sys_platform != "win32" or platform_machine != "ARM64"
# The opposite case: av publishes win_arm64 wheels from 17.0.0 only (cp311-abi3,
# plus a cp314t; there is no 3.13t wheel on any release).
av>=17.0.0; sys_platform == "win32" and platform_machine == "ARM64"

# cryptography 49.0.0 dropped the macosx_10_9_universal2 wheel for arm64-only, so
# x86_64 macOS has no wheel and builds the sdist, needing Rust plus a working
# linker. 48.0.1 is the newest release with a universal2 wheel. Lift when
# cryptography ships an x86_64-capable macOS wheel again.
cryptography<49; sys_platform == "darwin" and platform_machine == "x86_64"

# 46.0.3 is the newest cryptography with a win_arm64 wheel; raise the cap when upstream resumes.
cryptography<=46.0.3; sys_platform == "win32" and platform_machine == "ARM64"
