# torch is deliberately NOT pinned or listed.
#
# On ZeroGPU the CUDA build must match the platform's driver, and the Space image already provides
# a matching one; asking pip for a different torch - in particular the cpu-only wheel that keeps a
# non-GPU Space small - is the usual way a Space that works in a notebook fails on hardware.
#
# gradio is absent for the same class of reason: the Space installs the version pinned as
# `sdk_version` in README.md, and listing it here as well is how the two end up disagreeing.
# Leaving it unpinned in both places is what broke the first deploy - HF fell back to a gradio 3.x
# default with no `show_copy_button`.
#
# llama-cpp-python is deliberately ABSENT, and there is no longer a CPU runtime in `mimo.py` for it
# to serve. Both ways of installing it were tried here and both fail:
#
#   1. abetlen's prebuilt wheel index. Those wheels are tagged plain `linux_x86_64` rather than
#      `manylinux`, and they are linked against musl. pip installs one happily and then every
#      import dies with `libc.musl-x86_64.so.1: cannot open shared object file`, because a Space
#      runs on glibc.
#   2. the PyPI sdist, which is the only other option since PyPI publishes no binary wheel at all.
#      Compiling llama.cpp from source exceeded the Space build limit outright: `Job timeout`.
#
# The GPU path is therefore the only runtime, which is also the one that reproduces Part B exactly.
# The interface used to offer the choice; it no longer does, because a control whose second option
# can never work is worse than no control.

spaces                    # the @spaces.GPU decorator; ZeroGPU refuses to serve a Space without one
transformers>=4.45
accelerate                # device_map for the 4-bit load
bitsandbytes              # the NF4 quantisation Part B measured
sentencepiece
einops                    # nomic-embed-v1.5's remote code imports it
sentence-transformers>=3.0
huggingface_hub>=0.23
numpy
pandas
pyarrow                   # read the Part A embedding index

# --- the family-naming model -----------------------------------------------------------------
#
# scikit-learn is PINNED, and that is not caution for its own sake. `family_naming_model.pkl` is a
# pickled fitted estimator, and unpickling one across a scikit-learn minor version is best-effort at
# most: it either warns, or silently reconstructs an object whose internals have moved.
#
# The pin is 1.7.2 rather than something newer for a reason worth recording. A ZeroGPU Space runs
# **Python 3.10** and ignores a `python_version` override in README.md, and scikit-learn 1.8 requires
# >= 3.11 - so pinning 1.8 fails at pip with `No matching distribution found` and the Space never
# builds. 1.7.2 is the newest release that installs on 3.10, so the model is fitted with 1.7.2 too:
# App_Creation.ipynb Part 2 prints the version it used and records it inside the .pkl itself.
# Retrain and re-pin together, never one without the other.
scikit-learn==1.7.2
joblib                    # loads the fitted classifier
pymupdf                   # n_pages and page_text_chars, exactly as the corpus measured them