Call to pipeline.predict() fails
Author: s-udhaya
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 4.21.1
- Platform: macOS-12.5.1-arm64-arm-64bit
- Python version: 3.9.12
- Huggingface_hub version: 0.2.1
- PyTorch version (GPU?): 1.12.1 (False)
- Tensorflow version (GPU?): 2.9.2 (False)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: No
- Using distributed or parallel set-up in script?: No

### Who can help?

@narsil

### Information

- [ ] The official example scripts
- [X] 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

Execute the following piece of code resulted in an exception that is pasted below.

```python
from transformers import pipeline

pipe = pipeline("text-classification")
print(pipe.predict(["This restaurant is awesome"]))

```

Exception:

```
Traceback (most recent call last):
  File "pipeline_test.py", line 5, in <module>
    print(pipe.predict(["This restaurant is awesome"]))
  File "miniconda3/envs/mlflow-py3.9/lib/python3.9/site-packages/transformers/pipelines/base.py", line 840, in predict
    return self(X=X)
  File "miniconda3/envs/mlflow-py3.9/lib/python3.9/site-packages/transformers/pipelines/text_classification.py", line 138, in __call__
    result = super().__call__(*args, **kwargs)
TypeError: __call__() missing 1 required positional argument: 'inputs'
```

### Expected behavior

Successful predictions as shown below

```
[{'label': 'POSITIVE', 'score': 0.9998743534088135}]
```

### Proposed fix

I dig a bit deeper into the implementation based on the exception and found out that this [change](https://github.com/huggingface/transformers/compare/main...s-udhaya:transformers:fix_pipeline_predict#diff-441f558737166b045444da9c4be81f566b3d69054e8f20e288aed746a691fa61R845) fixes the issue. If this indeed a fix, I am happy to create a PR.

Comments:
Hi @s-udhaya ,

The code you're referring to is very old in the codebase and was created for compat with stuff like scikit-learn, over which I have very little knowledge.

The recommended way to call the pipeline is to do;

```python
from transformers import pipeline

pipe = pipeline("text-classification")
print(pipe("This restaurant is awesome"))
```


```python
from transformers import pipeline

def dataset():
    for i in range(1000):
       # Load from somewhere, a dataset, some file etc..
       yield "This restaurant is awesome"
       
pipe = pipeline("text-classification")
for out in pipe(dataset()):
    print(out)
```

Ofc you can send a list if you want, but it's not going to be used for batching any way (batching is an orthogonal concept in pipelines which you activate by using the parameter `pipeline(..., batch_size=n)`)

Hi @Narsil ,

Many thanks for the detailed response. Actually I am in the process of building a dedicated [Mlflow flavor for transformers](https://github.com/s-udhaya/mlflow/tree/add-transformers-flavor/mlflow/transformers) and I am heavily using this awesome pipeline abstraction as this drastically reduces the complexity of my implementation. 

As you could see [here](https://github.com/s-udhaya/mlflow/blob/add-transformers-flavor/examples/transformers/finetune_trainer_xlm_autolog.py), I use the recommended way to call the pipeline so far. However in order to have a unified interface across all mlflow model flavours, It is essential that the predict function to work. As far as I understand, this [fix](https://github.com/huggingface/transformers/compare/main...s-udhaya:transformers:fix_pipeline_predict#diff-441f558737166b045444da9c4be81f566b3d69054e8f20e288aed746a691fa61R845) should resolve the issue. Would you be kind enough to have a look at it, if you have time or redirect me to someone who can assist me in here?

Thanks again.

> As far as I understand, this [fix](https://github.com/huggingface/transformers/compare/main...s-udhaya:transformers:fix_pipeline_predict#diff-441f558737166b045444da9c4be81f566b3d69054e8f20e288aed746a691fa61R845) should resolve the issue.

The problem is that because the purpose of this code as since been lost, we would be very hesitant to change it because of our commitment to never make breaking changes.

> However in order to have a unified interface across all mlflow model flavours, It is essential that the predict function to work. 

If that is the core of the issue (which sounds odd) can't you just wrap the pipeline in another dummy object that just uses `predict` to use `__call__` ?

You can ofc open a PR with your proposed change and motivations. We will study it, and let others chime in if there is a good reason for the current code.

Hi @Narsil ,



> If that is the core of the issue (which sounds odd) can't you just wrap the pipeline in another dummy object that just uses `predict` to use `__call__` ?

This is exactly what happens in Pipeline's predict method. I would rather prefer to fix the issue at the source than creating a workaround.



> The problem is that because the purpose of this code as since been lost, we would be very hesitant to change it because of our commitment to never make breaking changes.

I understand your concern regarding breaking changes. however I believe, this change is not going to be a breaking change, and the predict function is not usable in its current state.

I will go ahead and create a PR. Prior to that I will run all the tests to make sure, the fix does not introduce any breaking changes. Let us see how it rolls :)

Thanks for the response.

> I will go ahead and create a PR. Prior to that I will run all the tests to make sure, the fix does not introduce any breaking changes. Let us see how it rolls :)

Thanks ! Again as I said, this is very old code maybe it broke a long time ago already and your PR is good (and we probably need to add a test to make sure we don't break again).

@Narsil Thanks for your input. I have created a PR with the fix and added few basic tests to make sure we don't break again. Please have a look at it whenever you have time and feel free to propose changes if necessary.