noamaanMulla-03/transformers-issues huggingface dataset:
fix: Add einops as a core dependency
Author: Hashbrownsss
Pull request: yes

# What does this PR do?

This PR addresses the `ModuleNotFoundError` for the `einops` library by adding it as a core dependency.

It fixes issue #39811, where certain parts of the `transformers` library, specifically in the flash attention code, were trying to import `einops` without it being a declared dependency. This bug prevented users from successfully running models that rely on this library.

By adding `einops` to `setup.py`, this PR ensures that the library is automatically installed for all users, making the `transformers` package more robust and reliable.

Fixes #39811


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case. This PR fixes issue #39811.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
    > This change is a dependency fix and does not require a documentation update.
- [ ] Did you write any new necessary tests?
    > This change is a dependency fix and does not require a new test. The existing test suite was used to confirm that the `einops` dependency is now correctly installed.


## Who can review?

@ArthurZucker 
@ivarflakstad 
@iforgetmyname 

Comments:
Hey! Thanks for the quick feedback. Although i couldnt find a dedicated npu extra. ive updated the PR to add einops to dev-torch instead, as it seems like the most apt place for the dependency I hope that works!

It seems like the einops dependency is only due to the un-/padding functions. It would be best to just rewrite them with normal torch and/or use the fa3 equivalents in the fa modeling utils file - no need for the einops dependency.

#40002 will probably remove the einops dependency but will keep you updated if not

That sounds good! I'll close this PR and keep an  eye on #40002
feat: Support tensor inputs in ImageClassificationPipeline
Author: Hashbrownsss
Pull request: yes

# What does this PR do?
Adds support for accepting numpy arrays and pytorch tensors as direct inputs to the 'ImageClassificationPipeline'. Currently the pipelines 'preprocess' function only accepts PIL images or file paths. Made the pipeline flexible to use with existing datasets and data pipelines as requested in the issue

Fixes #39607 


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case. (This was discussed in issue [#39607).](https://github.com/huggingface/transformers/issues/39607)
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

@Rocketknight1 
@zucchini-nlp 


Comments:
unpin torch<2.8 on circleci
Author: ydshieh
Pull request: yes

# What does this PR do?

revert #39951, as torchcodec 2.6.0 is released.

(without this unpin, we will get errors with torchcodec 2.6.0 + torch 2.7.1)

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40012). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
docs: fix duplication in 'en/optimizers.md'
Author: nevertmr
Pull request: yes

# What does this PR do?

This PR fixes a minor duplication in the code:
- "gradient_checkpointing=True"

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Documentation: @stevhliu
@Rocketknight1 

Thank you!


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40014). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Raising error when quantizing a quantized model
Author: MekkCyber
Pull request: yes

# What does this PR do?

This pr raises error if we try to quantize a quantized model using a different quantization method

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39998). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Update expected output values after #39885 (part 2)
Author: ydshieh
Pull request: yes

# What does this PR do?

The changes are expected.

I also change the atol and rtol to 1e-4

Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: dac, encodec

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40015). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
pin torchcodec==0.5.0 for now with torch 2.7.1 on daily CI
Author: ydshieh
Pull request: yes

# What does this PR do?

Will unpin this weekend.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40013). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix default values of getenv
Author: cyyever
Pull request: yes

# What does this PR do?

The default value of getenv should be a string or None.

Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: modernbert, whisper

Not sure about this one! I understand that envvars are all strings, but I think it's fine to set a non-string default when they're missing, right? Is there a PEP or Ruff rule about this?

Of course, https://docs.astral.sh/ruff/rules/invalid-envvar-default/

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39867). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[fix] Pass video inputs to plm
Author: 4g
Pull request: yes

1. video_inputs were not being passed to plm, resulting in same results for all videos.
2. This was breaking the official example. more @ https://github.com/huggingface/transformers/issues/40004
3. tested locally with different videos

# Pass video inputs to plm

Fixes # [40004](https://github.com/huggingface/transformers/issues/40004) 

 
## Who can review?
@zucchini-nlp




Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: perception_lm
[Feature Request] Automatically log parallelism configuration from Accelerate to W&B
Author: WoosungMyung
Pull request: no
Labels: name: Feature request

### Feature request

Automatically log parallelism configuration (TP, DP, etc.) from Accelerate to Weights & Biases config in `WandbCallback`.

Currently, when using `Accelerator`, parallelism sizes (e.g., `tp_size`, `dp_replicate_size`) must be manually recorded to `wandb.config`. These values are essential when conducting experiments with different distributed training. This feature request proposes automatically logging `parallelism_config._sizes` to Weights & Biases within `WandbCallback.on_train_begin()`, so that users do not have to manually add this information.




### Motivation

Currently, users must manually inject this information, and this process can and should be automated.
This improves reproducibility, saves developer time, and helps analyze the training environment in distributed learning environment using HF accelerate.


### Your contribution

I am happy to submit a PR. The PR would be minimal. The code will check if the model has an `accelerator` attribute and use the `_sizes` dictionary like so:

if hasattr(model, "accelerator"):
    wandb.config.update(model.accelerator.parallelism_config._sizes)

Thanks.

Comments:
cc @SunMarc @MekkCyber 

Hi @Rocketknight1 @SunMarc @MekkCyber 
Hi everyone! I’m still pretty new to OSS (only a couple of doc-fix PRs so far) and would love to grow by tackling this feature. I’ll add a simple hook  to push Accelerate’s parallelism sizes into wandb.config at train start (still reading more on this and plan is tentative for now but will soon open a PR!). Could you kindly assign #39882 to me? Thanks a lot!

Hi @akshay-babbar thanks for your interest in contributing 🤗 ! It seems that @WoosungMyung opened this feature request so that he could contribute this feature himself! Feel free contribute on any other issue or feature that looks important for you.
@WoosungMyung would be happy to review the pr

Hi @MekkCyber, @akshay-babbar!! 

Thanks for the clarification, and apologies if my initial request caused any confusion. Since I originally opened this feature request, I’d like to proceed with implementing it myself as planned. 

If there’s any functionality I’d like to see in the future but can’t implement myself, I’ll be sure to open a new issue and would be happy to reach out for your help.😊I truly appreciate your willingness to contribute, and I’ll open a PR for this one soon and keep everyone updated🤩

Thanks @MekkCyber @WoosungMyung for the clarification! i will try and find some other issue/feature to contribute on!!
Higgs modules_to_not_convert standardization
Author: MekkCyber
Pull request: yes

# What does this PR do?

Standardizes the way higgs quantization uses the `module_to_not_convert` attribute

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39989). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: higgs
Harmonize `past_key_value` to `past_key_valueS` everywhere
Author: Cyrilvallez
Pull request: yes

As per the title. I'm getting annoyed to see both, it was time to finally make it coherent everywhere. 
All the changes are made, so I'll only need to remove the decorators after next release (it's only internal modules, so no need for a long deprecation cycle)

Also reapplied modular to `examples/modular-transformer`

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39956). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: arcee, aria, autoformer, bamba, bart, bert, bert_generation, big_bird, bigbird_pegasus, biogpt, bitnet, blenderbot, blenderbot_small
remove `triton_kernels` dep with `kernels` instead
Author: SunMarc
Pull request: yes
Labels: name: for patch

# What does this PR do?

This PR remove `triton_kernels` dependency with `kernels` instead when using the new oai model gpt-oss

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39926). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Hi, may I ask why I can't find triton_kernels in kernels-community?

> Hi, may I ask why I can't find triton_kernels in kernels-community?


It is still private, it will switch it to public after this is merged ! 

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: mxfp4
Major issues with transformers version causing rubbish generations with Gemma3 family using vllm
Author: AbdelrahmanHagrass
Pull request: no
Labels: name: bug

### System Info

.

### Who can help?

Major issues with transformers version when used with Gemma3 family models on vllm. The output generations are incorrect and not usable—appears to be due to incompatibility or regression in transformers. Please advise on compatible versions or fixes.

Example: Generations are rubbish or meaningless compared to expected outputs.

Tested with latest vllm and Gemma3 models.

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

.

### Expected behavior

.

Comments:
Hey @AbdelrahmanHagrass , do you mean when using `model_impl='transformers'` with vLLM? I believe it is a known issue with sliding window, though ig it was fixed recently by @hmellor 

@AbdelrahmanHagrass could you share more information about what you're running? A minimal script or a `vllm serve ...` command

No i use the normal vllm serve , without changing the model_impl, it gives very random outputs. These guys have the same issue ,
https://github.com/vllm-project/vllm/issues/20341

So i should install the dev version or is it in the latest pip installation , also should i install the latest transformers version normally or a which version should make things go smother 

The linked PR solves the issue mentioned in that issue
Add support for SDPA for OWLViT and OWLv2
Author: mihaidusmanu
Pull request: yes

# What does this PR do?

Add support for SDPA (scaled_dot_product_attention) for efficient attention to OWLViT and OWLv2 models.
The previous code is used in the eager attention implementation. I roughly followed the SigLIP code for inspiration.
Note that we could do a larger refactory to use the is_causal flag, but I tried to stick as close as possible to the original implementation in this first version.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests? > I added an e2e sdpa inference test based on the fp16 one, but let me know if anything else is needed.

## Who can review?

Maybe @amyeroberts @qubvel @ArthurZucker 

Comments:
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: owlv2, owlvit
Tie weights recursively on all submodels
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

Fixes https://github.com/huggingface/transformers/issues/39900. Current code calls custom `_tie_weights` recursively on all `modules`, but does not recursively ties the embeddings or the encoder/decoder parts


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39996). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: blip, seamless_m4t, seamless_m4t_v2
Bnb failling tests
Author: MekkCyber
Pull request: yes

# What does this PR do?



Comments:
run-slow: bnb

This comment contains run-slow, running the specified jobs: 

models: []
quantizations: ['quantization/bnb'] ...

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40026). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Update expected values (after switching to A10) - part 4
Author: ydshieh
Pull request: yes

# What does this PR do?

As discussed offline, will merge to move fast as it's only expected outputs updated for A10

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39189). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: align, fastspeech2_conformer, focalnet, glpn, hiera, levit, lightglue, mgp_str, minimax, mixtral, moonshine, mpt, musicgen, musicgen_melody, sam, sam_hq

Hi @ydshieh, the call to `get_device_properties` in [tests/models/lightglue/test_modeling_lightglue.py](https://github.com/huggingface/transformers/pull/39189/files#diff-edf87762d9097b2b107dc32e688bf5c96cbec2f0ddf9f6f623ce43b50f6b2827) causes the test to for me when running on CPU:
```
    def _lazy_init():
        global _initialized, _queued_calls
        if is_initialized() or hasattr(_tls, "is_initializing"):
            return
        with _initialization_lock:
            # We be double-checked locking, boys!  This is OK because
            # the above test was GIL protected anyway.  The inner test
            # is for when a thread blocked on some other thread which was
            # doing the initialization; when they get the lock, they will
            # find there is nothing left to do.
            if is_initialized():
                return
            # It is important to prevent other threads from entering _lazy_init
            # immediately, while we are still guaranteed to have the GIL, because some
            # of the C calls we make below will release the GIL
            if _is_in_bad_fork():
                raise RuntimeError(
                    "Cannot re-initialize CUDA in forked subprocess. To use CUDA with "
                    "multiprocessing, you must use the 'spawn' start method"
                )
            if not hasattr(torch._C, "_cuda_getDeviceCount"):
>               raise AssertionError("Torch not compiled with CUDA enabled")
E               AssertionError: Torch not compiled with CUDA enabled
```
https://github.com/pytorch/pytorch/blob/0afaeb7c4ec7fd7ecd03e7553b170f76b348e782/torch/cuda/__init__.py#L382-L403

@rasmi 

Could you share the full trace log, and the command you used to run the thing?

Also, it looks like you try to use `cuda`  at some point while you torch is cpu-only version?

A dummy example 

```
(py39) λ python
Python 3.9.21 (main, Dec 11 2024, 16:35:24) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.tensor(3, device="cuda")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\yih-d\miniconda3\envs\py39\lib\site-packages\torch\cuda\__init__.py", line 363, in _lazy_init
    raise AssertionError("Torch not compiled with CUDA enabled")
AssertionError: Torch not compiled with CUDA enabled
>>>
```
fix `notification_service.py` about `time_spent`
Author: ydshieh
Pull request: yes

# What does this PR do?

We extract the information from test report file like in `1 passed in 7.89s`, but at some point, we do

> ... ["time_spent"] += time_spent[1:-1]

which remove the first digit. I am not guility!

Comments:
> Maybe formatting changed since the code was written?

or maybe it's just wrong even before I join HF 👀 won't try to figure it out

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40037). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[Florence-2] SyntaxWarning: invalid escape sequence '\d' in processing_florence2.py
Author: hookylee
Pull request: no
Labels: name: bug

### System Info

System Info
OS
nt
Python Version
3.12.10 (tags/v3.12.10:0cc8128, Apr 8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]
Embedded Python
false
Pytorch Version
2.7.0+cu128
Arguments
ComfyUI\main.py --windows-standalone-build
RAM Total
31.93 GB
RAM Free
9.09 GB
Devices

### Who can help?

hookylee@gmail.com

Hi Transformers team,

While using the Florence-2-base-ft model through HuggingFace Transformers, I encountered the following Python warning:

SyntaxWarning: invalid escape sequence '\d'
C:\Users\[USER]\.cache\huggingface\modules\transformers_modules\Florence-2-base-ft\processing_florence2.py:515

This comes from the following code in `processing_florence2.py`:
PATTERN: 'r<time_(\d+)><time_(\d+)>([a-zA-Z0-9 ]+)'

The issue is that the regex pattern is written as a regular string instead of a **raw string**, causing Python to interpret `\d` as an invalid escape sequence.

**Suggested fix:**
Change this:
PATTERN: 'r<time_(\d+)><time_(\d+)>([a-zA-Z0-9 ]+)'

To this:
PATTERN: r'<time_(\d+)><time_(\d+)>([a-zA-Z0-9 ]+)'

This will avoid the SyntaxWarning during runtime.

Thank you for maintaining this library and for the Florence-2 integration!


### Information

- [ ] The official example scripts
- [x] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [x] My own task or dataset (give details below)

### Reproduction

...

### Expected behavior

...

Comments:
Hi @hookylee, thank you for the feedback! The Florence-2 code is currently [being ported into the main Transformers library](https://github.com/huggingface/transformers/pull/38188/), and I've added this as a suggestion. 

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.

Was trying to track this down and it annoyingly showed up on my system as `<unknown>:515: SyntaxWarning: invalid escape sequence '\d'`

Thanks for reporting.