# The declared floors, pinned exactly. Installable, and installed by the
# `dependency-floor` CI job.
#
# Why this file has to exist: pip has no "resolve to the lowest permitted
# version" mode. A floor of `transformers>=4.56` is satisfied by whatever is
# newest, so a job that only reads pyproject tests the ceiling and calls it the
# floor. Every direct dependency therefore gets an `==` here, and this file is
# what makes the floor claim measurable.
#
# torch is deliberately absent: its CPU wheels live outside PyPI, so the job
# installs it by hand from the torch index before applying these. Its floor is
# version-dependent (see pyproject) and cannot be expressed as one pin.
#
# When a floor in pyproject changes, change it here in the same commit. A
# mismatch means the job is testing a version nothing declares.

transformers==4.56
accelerate==0.26
pyarrow==14
huggingface_hub==0.34.0
# numpy is not a declared dependency of this project and is pinned here anyway, because the floor
# combination is otherwise not installable. pyarrow 14's extension modules are compiled against
# numpy 1 and its metadata says only `numpy>=1.16.6`, so the resolver is free to pair it with
# numpy 2 and did: the floors job failed with "ImportError: numpy.core.multiarray failed to
# import" from `pyarrow.lib`. Users are unaffected, because pip gives them a recent pyarrow; it is
# the FLOOR claim that was incoherent. 1.26.4 is the last numpy 1 and supports Python 3.10.
numpy==1.26.4
# 4.0, not 3.1. `head-to-head/best_of_n_heretic.py` imports
# `optuna.storages.journal.JournalFileBackend`, which arrived in Optuna 4.0; at 3.1 the floors job
# died at collection with "No module named 'optuna.storages.journal'". A floor the project's own
# suite cannot pass is not a floor, it is a number.
optuna==4.0.0
# Both of these were declared with a floor and pinned nowhere, so the floors job resolved them
# to whatever was newest and called it the floor. `gguf` is precisely the dependency where an
# untested floor has already bitten this project: PyPI gguf 0.19.0 and llama.cpp's own gguf-py
# 0.19.0 are different code sharing a version number. Checked against PyPI on 2026-09-08: 0.19.0
# ships a py3 wheel, and sentencepiece 0.1.98 ships cp310 wheels, so both install on the Python
# this job runs.
gguf==0.19.0
sentencepiece==0.1.98

# The dev extra, because `pip install -e '.[dev]'` at the floors is a real
# thing a contributor does, and the suite has to pass there too.
#
# `datasets` moved out of the runtime dependencies and into the `hub` extra when
# `trackio.py` took over reading and writing tracks, but its floor still has to be
# tested: `[dev]` installs it so the suite can assert that both backends read and
# write the same bytes, and 2.15 against pyarrow 14 is exactly the pairing the
# pyproject comments describe.
datasets==2.15
pytest==7.0.0
pytest-cov==4.0.0
build==1.0.0
shtab==1.6.0
# Test-only, and only where `tomllib` is not in the standard library.
tomli==2.0.0
# ruff is already pinned exactly in pyproject, so it has no floor to test.

# bitsandbytes (the `quant` extra) is absent: it is not installed by `[dev]`,
# needs CUDA to do anything, and the CI runners have no GPU.
