[CI] [GHA] Introduce additional Python (3.9-3.12) API tests on Windows

[akashchi]

Tickets:

• 152705

[mryzhov]

I would suggest a bit different approach to find and install wheels, to simplify support in future:

For example how to call this action:
# Install Python benchmark_app by installing openvino-*.whl
- name: Install OpenVINO Python wheels
uses: ./openvino/.github/actions/install_ov_wheels
with:
wheels-dir-path: ${{ env.INSTALL_WHEELS_DIR }}
install-wheels: |
- openvino[extra]
- openvino-dev
- openvino-tokenizers
- openvino-genai

And inside the action we could use the following installation aproach:

pip install openvino[extra] openvino-dev openvino-tokenizers --find-links ${{ env.INSTALL_WHEELS_DIR }} --no-index --no-cache

@ilya-lavrenov , @akladiev what do you think?

[mryzhov]

pip will find the suitable weel by himself and do not pickup it from PyPI

[akashchi]

There is a problem with this approach: since the idea is to use --no-index so that pip does not try to install any local wheels from PyPI instead, it cannot install the dependencies because it is forbidden from trying to access PyPI like in https://github.com/openvinotoolkit/openvino/actions/runs/11794716928/job/32855012693#step:7:43. The wheels have many dependencies that are hosted on the package index hence we cannot restrict the pip from accessing the index.

[mryzhov]

ok, but the 1st comment is still actual, I think it is better to make action more universal (just provide the wheel pattern names as argument)

[akladiev]

Actually, to make sure that a local wheel is installed, internally we pass the expected package version like this pip install openvino-dev==2025.0.0.dev20241113 --find-links.... So there is no need for --no-index. Package version is saved to our manifest file before build starts (field wheel_product_version).

[akashchi]

I think that we should proceed with the current approach: using the openvino openvino_tokenizers ... as the input and iterating over the given wheel names for installation.
Additionally, the openvino_tokenizers wheel has a different version for some reason:

so we would not be able to use it for local installation. Also, it would be rather cumbersome to pass the version from the build job to other jobs in which the wheels are used.