chore: update constraints-dev.txt (2026-01-19)

[courtneypacheco]

This PR updates the constraints-dev.txt file using tox -e constraints.

Summary by CodeRabbit

• Chores
  • Updated development dependencies to latest compatible versions for improved ecosystem alignment.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

This pull request has been automatically marked as stale because it has not had activity within 90 days. It will be automatically closed if no further activity occurs within 30 days.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. @courtneypacheco please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[coderabbitai]

📝 Walkthrough

Walkthrough

A single file update to constraints-dev.txt that bumps versions across numerous package dependencies. Both direct packages and transitive dependencies were updated to align with newer ecosystem requirements while maintaining existing functionality.

Changes

Cohort / File(s)

Summary

Development Dependency Versions constraints-dev.txt

Updated 128 package version specifications across accelerate, aiofiles, aiohttp, anyio, attrs, beautifulsoup4, bleach, cachetools, certifi, cffi, charset-normalizer, click, datasets, deepspeed, einops, fsspec, gitpython, grpcio, ipykernel, ipython, isort, jsonschema, jupyter-server, llvmlite, markdown, mistune, mypy, nbclient, nbconvert, nbformat, networkx, notebook, numba, numpy, pyarrow, pydantic, pillow, pre-commit, protobuf, pyyaml, pyzmq, pytest, requests, rich, ruff, safetensors, setuptools, tokenizers, torch, tornado, transformers, triton, typing-extensions, and yarl. All changes are version pin updates; no control flow or error handling modifications.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰✨ A version hop, a dependency skip,
Numbers dance on the constraint trip,
Packages aligned, dependencies tight,
The ecosystem grows, oh what a sight!
Bumps and bounds in dev delight! 🚀

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: updating the constraints-dev.txt file with a date stamp indicating when the update was performed.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@constraints-dev.txt`:
- Around line 189-197: The pinned pairing of torch==2.6.0 and triton==3.2.0 may
fail on some platforms (notably Windows) and in DeepSpeed/Ray Train contexts;
reproduce by running a quick smoke test: import torch, call
torch.cuda.is_available(), and run a small CUDA matmul to confirm imports and
GPU functionality. If you encounter import errors (missing symbols like
AttrsDescriptor on Windows) or autotuner/runtime failures, update the
constraints by switching to a known-good pair (e.g., torch==2.5.1 with triton
3.1.x) or bump both to a newer released compatible pair, and document the test
results and chosen fallback in the constraints comment so CI/platform owners can
verify.
- Around line 151-153: The LoraOptions dataclass uses a v1-style inner class
Config; replace that with Pydantic v2 syntax by adding model_config =
ConfigDict(use_enum_values=True) on LoraOptions (and remove the class Config
block) so enum serialization follows v2 semantics, then run tests. Also verify
wandb compatibility by checking the installed wandb version for known
UnsupportedFieldAttributeWarning with Pydantic 2.12+ and either
upgrade/downgrade wandb to a version that suppresses the warning or pin wandb
accordingly. Finally, tighten the pydantic requirement in requirements (change
loose "pydantic>=2.7.0" to a constrained range like "pydantic>=2.7.0,<2.13" or a
specific 2.12.x) after confirming tests pass.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Pydantic 2.12.x breaking changes migration guide

💡 Result:

Below are the important breaking changes introduced in Pydantic 2.12.x and a short, actionable migration checklist.

Key breaking changes (what changed and impact)

• JSON Schema: dict-valued json_schema_extra is now merged rather than replaced — adjust code that relied on previous replace semantics when generating/modifying JSON Schema. [1]
• Annotation handling/refactor: annotation injection for known/generic types was refactored and some annotation compatibility errors are moved to validation-time (not import-time) — tests that previously passed may now raise validation errors at runtime. Audit generics, Annotated metadata, and any custom Generic model usage. [1]
• serialize_as_any / serialization behavior: serialize-as-any behavior changed (affects custom serializers, computed fields, and RootModel serialization); existing serializers may need updates. New flags like exclude_computed_fields and serialize options were added. Run serialization tests and review custom serializer implementations. [1][2]
• Removal/changes in internal metadata: typed_dict_cls removed from CoreMetadata; don’t rely on that internal metadata. [1]
• JSON Schema 'allOf' workarounds removed — code expecting the old workarounds in generated JSON Schema should be updated. [1]
• Examples API: passing a dict to Examples is deprecated — update any code constructing Examples from dicts. [1]
• Validator/validator-signature behavior: some changes to validator inspection and error messages (including fixes around evaluating annotations) — review model validators and after-model validators (classmethod after-model validators previously erroring were later changed to emit warnings in patch releases). [1][2]
• Python 3.14 compatibility notes / MISSING sentinel: new MISSING sentinel and initial Python 3.14 support; be aware of MISSING semantics and Python-version-specific edge cases. [1][2]

Migration checklist (practical steps)

1. Read the 2.12 changelog and release notes (linked below) to see full list of changes and follow-up patch fixes. [1][2].
2. Pin pydantic-core to the compatible version used by 2.12 (use the release notes / pip metadata) and run your test suite under the target Python versions you support (especially 3.10–3.14). [2]
3. Run the whole test suite with strict failure (serialization, validation, JSON schema, and any runtime-generate-schema code). Fix failures in:
   • custom validators/serializers (update signatures or logic per new inspection rules). [1][2]
   • serialization paths relying on serialize_as_any, RootModel, or computed fields (consider new exclude_computed_fields option). [1][2]
   • JSON Schema generation code (handle merged json_schema_extra; remove assumptions about 'allOf' workarounds). [1]
4. Replace any reliance on internal CoreMetadata fields (typed_dict_cls) and stop passing dicts to Examples. [1]
5. If you used Annotated metadata mutability patterns (re-using FieldInfo objects), review and replace with supported patterns (docs/examples updated). [2]
6. If you saw after-model validator classmethod errors in 2.12.0, update to accept the new behavior or apply the patched warning semantics in later 2.12.x patch releases; consult the 2.12.x changelog for which patch fixed/regressed which behaviour. [2]
7. When upgrading in production: roll out in a canary environment, pin to an explicit 2.12.x patch (not just 2.12), and iterate fixes before wide rollout.

Important links (read first)

• Official changelog (detailed breaking-change list + patch notes). [1]
• GitHub release notes for v2.12 (notes on specific fixes and follow-up patch releases). [2]
• v2.12 announcement / upgrade blog post (high-level highlights and migration pointers). [3]
• Version-compatibility policy (what the project considers breaking vs. allowed changes). [4]

References
[1] Pydantic changelog (v2.12 section).
[2] Pydantic GitHub releases (v2.12.0 → v2.12.x).
[3] Pydantic v2.12 announcement blog post.
[4] Pydantic version compatibility docs.

Would you like a targeted migration patch plan for your codebase? If so, paste a few representative models/serializers/validator snippets and I’ll produce exact changes.

---

🏁 Script executed:

# Check constraints-dev.txt for full context
head -n 160 constraints-dev.txt | tail -n 30

Repository: instructlab/training

Length of output: 1701

---

🏁 Script executed:

# Search for Pydantic imports and usage in codebase
rg -i "from pydantic|import pydantic" --type py -A 2 | head -50

Repository: instructlab/training

Length of output: 360

---

🏁 Script executed:

# Check for Pydantic model definitions in codebase
rg "BaseModel|ConfigDict|field_validator" --type py | head -30

Repository: instructlab/training

Length of output: 1015

---

🌐 Web query:

deepspeed pydantic 2.12 compatibility

💡 Result:

Short answer: DeepSpeed has migrated to Pydantic v2 (PRs/merges for v2 support exist), so it is generally compatible with Pydantic v2 releases — but you must use a matching pydantic_core version (Pydantic v2.12 enforces an exact pydantic-core pairing). If you see errors, upgrade DeepSpeed to the latest release/commit and ensure pydantic and pydantic-core versions match. (app.semanticdiff.com)

What to do if you hit problems

• Upgrade DeepSpeed (pip install --upgrade deepspeed or use the repo's latest master/commit where Pydantic v2 migration was merged). (pypi.org)
• Install matching pydantic_core for your pydantic version (Pydantic v2.12 will error if pydantic_core is incompatible). (pydantic.dev)
• If errors persist, check DeepSpeed GitHub issues for similar reports (there are older pydantic-related issues) and file an issue with your ds_report output. (github.com)

If you want, tell me the DeepSpeed version and your installed pydantic / pydantic-core versions and I’ll verify compatibility and give exact pip commands.

Citations:

• 1: https://app.semanticdiff.com/gh/deepspeedai/DeepSpeed/pull/5167/commits?utm_source=openai
• 2: https://pypi.org/project/adeepspeed/?utm_source=openai
• 3: https://pydantic.dev/articles/pydantic-v2-12-release?utm_source=openai
• 4: [BUG] The latest master code doesn't work with pydantic 2.0a2 deepspeedai/DeepSpeed#3280

---

🌐 Web query:

wandb pydantic 2.12 compatibility requirements

💡 Result:

Short answer: Recent wandb SDK releases declare pydantic v2 compatibility (wandb added pydantic>=2.6,<33 in v0.19.0 and later relaxed support for v1/v2), so pydantic 2.12 is within the allowed range — but there are user-reported warnings/bugs when importing wandb with pydantic 2.12 that may require a patch or a temporary pin to an earlier 2.x release. [1][2][3]

Details / action:

• wandb declared pydantic>=2.6,<33 as a dependency (v0.19.0+). [1]
• Pydantic 2.12 was released upstream. [3]
• There is a reported wandb GitHub issue describing warnings with pydantic 2.12+ (UnsupportedFieldAttributeWarning); consider pinning to a known-working 2.x (e.g., 2.11.x) until a wandb fix/release resolves it. [2]

Sources:
[1] wandb SDK release notes (v0.19.0 / changelog).
[2] wandb GitHub issue reporting UnsupportedFieldAttributeWarning with Pydantic 2.12+.
[3] Pydantic v2.12 release announcement.

---

🏁 Script executed:

# Read the config.py file to check for usage patterns affected by breaking changes
wc -l src/instructlab/training/config.py

Repository: instructlab/training

Length of output: 102

---

🏁 Script executed:

# Check the actual config.py implementation
cat -n src/instructlab/training/config.py | head -100

Repository: instructlab/training

Length of output: 3328

---

🏁 Script executed:

# Continue reading config.py to see model implementations and validators
cat -n src/instructlab/training/config.py | tail -n +100 | head -150

Repository: instructlab/training

Length of output: 5630

---

🏁 Script executed:

# Check if there are any custom serializers, computed fields, or RootModel usage
rg -i "computed_field|root_model|field_serializer|model_serializer|serialize_as_any" --type py

Repository: instructlab/training

Length of output: 46

---

🏁 Script executed:

# Check for any JSON schema generation or Examples usage in config
rg "json_schema|Examples|model_json_schema" --type py

Repository: instructlab/training

Length of output: 46

---

🏁 Script executed:

# Check rest of config.py for more details on LoraOptions and any other Config class usage
cat -n src/instructlab/training/config.py | sed -n '135,200p'

Repository: instructlab/training

Length of output: 2234

---

🏁 Script executed:

# Search for any old-style Config class usage (v1 pattern)
rg "class Config:" --type py -B 5

Repository: instructlab/training

Length of output: 413

---

🏁 Script executed:

# Check requirements.txt and constraints-dev.txt to understand version pinning strategy
cat requirements.txt | grep -i "pydantic\|deepspeed\|wandb"

Repository: instructlab/training

Length of output: 79

---

Migrate LoraOptions to Pydantic v2 ConfigDict and evaluate wandb compatibility with 2.12.5.

Pydantic 2.12.5 has documented breaking changes (JSON Schema merging, annotation handling, serialization behavior, and validator signatures). The pinned versions are compatible with deepspeed and pydantic-core, but:

1. LoraOptions (line 135–136) uses deprecated v1-style class Config: — migrate use_enum_values = True to model_config = ConfigDict(use_enum_values=True) to ensure proper v2 behavior.

2. wandb has reported UnsupportedFieldAttributeWarning issues with Pydantic 2.12+ — confirm that the current wandb version resolves these warnings, or consider pinning to an earlier 2.x release (e.g., 2.11.x) as a temporary workaround until wandb releases a compatible patch.

3. Loosen the pydantic constraint in requirements.txt — currently pydantic>=2.7.0 is too broad given 2.12.x breaking changes; update to pydantic>=2.7.0,<2.13 or explicit 2.12.x series if testing confirms stability.

🤖 Prompt for AI Agents

In `@constraints-dev.txt` around lines 151 - 153, The LoraOptions dataclass uses a
v1-style inner class Config; replace that with Pydantic v2 syntax by adding
model_config = ConfigDict(use_enum_values=True) on LoraOptions (and remove the
class Config block) so enum serialization follows v2 semantics, then run tests.
Also verify wandb compatibility by checking the installed wandb version for
known UnsupportedFieldAttributeWarning with Pydantic 2.12+ and either
upgrade/downgrade wandb to a version that suppresses the warning or pin wandb
accordingly. Finally, tighten the pydantic requirement in requirements (change
loose "pydantic>=2.7.0" to a constrained range like "pydantic>=2.7.0,<2.13" or a
specific 2.12.x) after confirming tests pass.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

torch 2.6.0 CUDA driver requirements compatibility

💡 Result:

Short answer: PyTorch (torch) 2.6.0 Linux binaries are built/shipped with CUDA 12.6.3; that CUDA version requires NVIDIA driver 560 or newer. [1][2]

Sources:

• PyTorch 2.6 release notes (binaries shipped with CUDA 12.6.3). [1]
• NVIDIA PyTorch release notes / driver requirements (CUDA 12.6.3 → NVIDIA driver 560+). [2]

---

🌐 Web query:

triton 3.2.0 CUDA requirements

💡 Result:

Triton 3.2.0 requires CUDA 12 (wheels bundle a CUDA 12.4 toolchain); CUDA 11 and older are not supported. The Triton 3.2 series is intended to be used with PyTorch ≥ 2.6 (if using with PyTorch). [1][2]

Sources:

• Triton Windows / PyPI notes (bundled CUDA 12.4; CUDA 12 required). [1]
• Libraries.io / PyPI summary (Triton 3.2 → CUDA 12.4; PyTorch ≥2.6). [2]

---

🌐 Web query:

torch 2.6.0 triton 3.2.0 compatibility issues

💡 Result:

Short answer: PyTorch 2.6.0 expects Triton 3.2.x, but there are several reported compatibility / packaging problems with that pairing (especially on Windows and in some runtime combos).

Key points and evidence

• PyTorch→Triton mapping: torch 2.6 is intended to work with Triton 3.2.0. [1]
• Windows packaging: on Windows (and certain Python versions) the bundled "triton-windows" runtime that ships with PyTorch is missing symbols (e.g., AttrsDescriptor) and can cause import failures. This is a known issue. [2]
• Runtime/autotuner errors: Triton 3.2.0 added autotuner logic that can check torch.cuda.is_available(), which has caused runtime failures with combos like torch 2.6.0 + triton 3.2.0 (e.g., Deepspeed / Ray Train repros). [3]

Practical fixes

• Use the officially matched combo on Linux (PyTorch 2.6 + triton 3.2 wheel) when possible. [1]
• On Windows or on Python versions where official Triton wheels are missing, avoid relying on the bundled triton-windows (use Linux or a different Python), or wait for/seek an updated triton-windows that restores missing symbols. [2]
• If you hit autotuner / import errors, try a temporary workaround: downgrade Triton (or PyTorch) to a known-working pair (e.g., torch 2.5.1) or upgrade PyTorch/Triton to versions where the issue is resolved. [3]

Sources
[1] triton-windows / docs (PyTorch ↔ Triton mapping). (github.com)
[2] GitHub issue: ImportError AttrsDescriptor missing (Windows + torch 2.6.0 + triton). (github.com)
[3] Ray / Deepspeed GitHub issue reporting Triton 3.2.0 autotuner causing failures with torch 2.6.0. (github.com)

If you want, tell me your OS, Python and CUDA versions and the exact error/logs and I’ll suggest the most direct workaround.

Citations:

• 1: https://github.com/woct0rdho/triton-windows?utm_source=openai
• 2: [Windows][Python 3.12] Torch 2.6.0+cu124 fails with Triton ImportError: AttrsDescriptor missing pytorch/pytorch#170508
• 3: [Train] Deepspeed + Triton 3.2.0 + Torch 2.6.0 has issues with Ray Train ray-project/ray#50406

---

Test torch 2.6.0 + triton 3.2.0 pairing on your platform; known Windows packaging and DeepSpeed/Ray Train incompatibilities exist.

While torch 2.6.0 and triton 3.2.0 are officially paired (both use CUDA 12.x; driver 560+ required for CUDA 12.6.3), this combination has reported issues:

• Windows: bundled triton-windows is missing symbols (e.g., AttrsDescriptor), causing import failures.
• Runtime: triton 3.2.0's autotuner can fail with torch.cuda.is_available() checks in DeepSpeed/Ray Train contexts.

Run a smoke test (import torch, torch.cuda.is_available(), small matmul) on your target platform(s) and Python version(s). On Windows or if you hit autotuner errors, consider downgrading to torch 2.5.1 (with triton 3.1.x) or upgrading both to a newer released pair.

🤖 Prompt for AI Agents

In `@constraints-dev.txt` around lines 189 - 197, The pinned pairing of
torch==2.6.0 and triton==3.2.0 may fail on some platforms (notably Windows) and
in DeepSpeed/Ray Train contexts; reproduce by running a quick smoke test: import
torch, call torch.cuda.is_available(), and run a small CUDA matmul to confirm
imports and GPU functionality. If you encounter import errors (missing symbols
like AttrsDescriptor on Windows) or autotuner/runtime failures, update the
constraints by switching to a known-good pair (e.g., torch==2.5.1 with triton
3.1.x) or bump both to a newer released compatible pair, and document the test
results and chosen fallback in the constraints comment so CI/platform owners can
verify.