requirements: relax torch~=2.6.0 to torch>=2.6.0 for convert_hf_to_gguf#23503
Conversation
The ~=2.6.0 operator resolves to >=2.6.0, <2.7.0, which fails on PyPI for platform/CPython combinations where 2.6.x is not present. The accompanying comment already says 'PyTorch 2.6.0 or later', so the looser >=2.6.0 matches the documented intent and unblocks pip install -r requirements/requirements-convert_hf_to_gguf.txt. Fixes ggml-org#23408
|
The pinning was by design, however we should bump it now due to various compatibility reasons, possibly to |
|
Bumped the pin to torch>=2.11.0 in 05935c9 per your suggestion. Updated the comment to note the bump while preserving the original Embedding Gemma context. Let me know if you would prefer a different operator (~=2.11.0 to keep major-version pinning) or a different floor. |
|
FYI we started pinning package versions ever since the LiteLLM supply-chain attack. You may wish to read more about our security and preventative measures here: #20954 We will not allow the use of the |
taronaeo
left a comment
taronaeo
left a comment
There was a problem hiding this comment.
Might need to update ggml-org/ggml's requirements.txt as well since it follows llama.cpp.
Oh, right. We should look into moving the lower end of |
|
|
|
Pushed f851ecd to bump tools/mtmd/requirements.txt to torch==2.11.0 and torchvision==0.26.0, with the s390x nightly carve-out so it stays consistent with the main requirements file. |
|
LOL, CI didn't like that, wonder why it doesn't trigger on |
The check_requirements script flags '==' on lines in files matched by */**/requirements*.txt. Append the documented suppression comment to the pinned torch and torchvision lines (and to the s390x platform marker lines) so the check passes while keeping the pins required by project policy.
|
There's also this, though not sure why that changed: |
|
Looked at the failing type-check. The error is in examples/model-conversion/scripts/embedding/run-original-model.py:67: config = model[0].auto_model.config ty now reports model[0] as Tensor | Module and Tensor has no auto_model. The line itself was not touched by this PR, but the new torch wheels carry stricter stubs which is why the error showed up only after the bump. Two options I can see:
Happy to push either, just want to confirm you would rather see this fixed inline on this PR than punted to a follow-up. The transformers job not triggering on its own bump looks like a path-filter quirk in the workflow, I can dig into that separately if useful. |
Yeah, noticed, wonder why it would be typed that way?
Do that, behavior should be unchanged, so this is something that should be fixed separately if it's an actual issue.
Yes please. |
With torch 2.11.0 stubs, nn.Sequential.__getitem__ now returns Tensor | Module rather than Module, so model[0].auto_model fails ty on the SentenceTransformer code path. The runtime behavior is unchanged because SentenceTransformer always wraps a Module at index 0. Adding a targeted unresolved-attribute ignore keeps the type-check green without altering behavior. A follow-up issue tracks typing the variable explicitly.
|
Pushed 6fca63c with the targeted ignore on examples/model-conversion/scripts/embedding/run-original-model.py:67. Filed #23576 to track typing the variable explicitly so the ignore can be removed. On the path-filter question: the python-type-check workflow already watches */requirements.txt and **.py, so the transformers 5.5.1 bump in #21617 did trigger the workflow and the type-check job ran green. What changed here is the content of the torch stubs, not whether the workflow fires. The transformers 5.5.1 bump did not touch torch, so nn.Sequential.getitem kept returning Module and the SentenceTransformer line stayed quiet. Bumping to torch 2.11.0 swapped that signature to Tensor | Module, which is the first time the existing line surfaced an error. So the workflow path filter is fine, the trigger you may have wanted is some kind of stub-aware run on dependency bumps, which I do not think is easy to wire up generically. Let me know if you want me to file a separate issue to track that too. |
It's not the type-check that fails, but check-requirements, and it should have failed for that bump as well.
Well, why did the signature change, and is that a potential issue? |
* requirements: relax torch~=2.6.0 to torch>=2.6.0 for convert_hf_to_gguf The ~=2.6.0 operator resolves to >=2.6.0, <2.7.0, which fails on PyPI for platform/CPython combinations where 2.6.x is not present. The accompanying comment already says 'PyTorch 2.6.0 or later', so the looser >=2.6.0 matches the documented intent and unblocks pip install -r requirements/requirements-convert_hf_to_gguf.txt. Fixes ggml-org#23408 * requirements: bump torch floor to 2.11.0 per maintainer * requirements: pin torch to ==2.11.0 per project policy * requirements: pin mtmd torch and torchvision to 2.11.0/0.26.0 per project policy * requirements: suppress check_requirements pin warning on mtmd The check_requirements script flags '==' on lines in files matched by */**/requirements*.txt. Append the documented suppression comment to the pinned torch and torchvision lines (and to the s390x platform marker lines) so the check passes while keeping the pins required by project policy. * ty: silence Tensor/Module union check on model[0].auto_model With torch 2.11.0 stubs, nn.Sequential.__getitem__ now returns Tensor | Module rather than Module, so model[0].auto_model fails ty on the SentenceTransformer code path. The runtime behavior is unchanged because SentenceTransformer always wraps a Module at index 0. Adding a targeted unresolved-attribute ignore keeps the type-check green without altering behavior. A follow-up issue tracks typing the variable explicitly.
* requirements: relax torch~=2.6.0 to torch>=2.6.0 for convert_hf_to_gguf The ~=2.6.0 operator resolves to >=2.6.0, <2.7.0, which fails on PyPI for platform/CPython combinations where 2.6.x is not present. The accompanying comment already says 'PyTorch 2.6.0 or later', so the looser >=2.6.0 matches the documented intent and unblocks pip install -r requirements/requirements-convert_hf_to_gguf.txt. Fixes ggml-org#23408 * requirements: bump torch floor to 2.11.0 per maintainer * requirements: pin torch to ==2.11.0 per project policy * requirements: pin mtmd torch and torchvision to 2.11.0/0.26.0 per project policy * requirements: suppress check_requirements pin warning on mtmd The check_requirements script flags '==' on lines in files matched by */**/requirements*.txt. Append the documented suppression comment to the pinned torch and torchvision lines (and to the s390x platform marker lines) so the check passes while keeping the pins required by project policy. * ty: silence Tensor/Module union check on model[0].auto_model With torch 2.11.0 stubs, nn.Sequential.__getitem__ now returns Tensor | Module rather than Module, so model[0].auto_model fails ty on the SentenceTransformer code path. The runtime behavior is unchanged because SentenceTransformer always wraps a Module at index 0. Adding a targeted unresolved-attribute ignore keeps the type-check green without altering behavior. A follow-up issue tracks typing the variable explicitly. (cherry picked from commit c0c7e14)
3 participants
Fixes #23408.
The ~=2.6.0 operator means >=2.6.0, <2.7.0, which fails to resolve on PyPI for some platform/CPython combinations where a 2.6.x wheel is not present. The accompanying comment already says 'PyTorch 2.6.0 or later', so the looser >=2.6.0 matches the documented intent and unblocks pip install -r requirements/requirements-convert_hf_to_gguf.txt.