PyPI 1.16.0 release requires specifying the execution provider during InferenceSession creation

[cbourjau]

Describe the issue

The latest 1.16.0 CPU-release (aka onnxruntime) on PyPI appears to have AzureExecutionProvider as a default provider (introduced by #17025 ?). This means that the EP is now ambiguous with respect to the second default CPUExecutionProvider causing an exception:

ValueError: This ORT build has ['AzureExecutionProvider', 'CPUExecutionProvider'] enabled. Since ORT 1.9, you are 
required to explicitly set the providers parameter when instantiating InferenceSession. For example, 
onnxruntime.InferenceSession(..., providers=['AzureExecutionProvider', 'CPUExecutionProvider'], ...)

The text in the exception is misleading. I just checked and as of 1.15.1 it was not necessary to specify an explicit provider through the Python interface. No warning is given in 1.15.1 about this change either.

This is a breaking change in the Python interface. Furthermore, the choice of making the AzureExecutionProvider EP one of the defaults seems strange given that it appears to be undocumented.

To reproduce

Create an inference session via the Python API (using a random model from the onnx/onnx repository):

import onnxruntime as ort
ort.InferenceSession("onnx/onnx/backend/test/data/node/test_abs/model.onnx")

Urgency

This is a breaking change with no prior warnings on possibly the most common way to initialize a session.

Platform

Mac

OS Version

12.3.1

ONNX Runtime Installation

Released Package

ONNX Runtime Version or Commit ID

1.16.0

ONNX Runtime API

Python

Architecture

X64

Execution Provider

Default CPU

Execution Provider Library Version

No response

Edit: Clarified that this is about the CPU-release

[tianleiwu]

The providers parameter is required for onnxruntime-gpu 1.15.1 in linux/windows.

Maybe this issue is for cpu-only package.

[cbourjau]

Yes, this is for the cpu package, or at least that is what I think. I installed using:

$ pip install onnxruntime==1.16

[pranavsharma]

Yes, this looks like a valid issue. The workaround is to explicitly supply the CPUExecutionProvider in the list. @RandySheriff - can you take a look?

[ahmedharbaoui]

+1 also having this issue

[mshr-h]

1.16.1 was released with the below fix commit.
1c245e6