fix: do not let uv create the virtual environment

[SMoraisAnsys]

This PR homogenize the creation of virtual environments in build-wheelhouse and check-license actions by creating the venv using python.

---

Tip

Using uv to create the venv can lead to a situation where uv installs a new version of python. Recently I was refactoring pyaedt's GH workflow and one of them consist in creating a wheelhouse in Rocky Linux. However, the python provided by actions/setup-python do not work due to GLIC incompatibility. Instead of failing, the workflow kept moving and uv was installing a new python version under the hood. Note that this python is compatible with the Rocky Linux container and allow us to proceed smoothly.

Extra question: should we allow the use of python uv when setting python through our action ? Here could be the associated implementation #1219

[AlejandroFernandezLuces]

LGTM, I would have preferred to use the faster uv command to be favoured, but I understand the issue you mentioned.

[RobPasMue]

LGTM!

[SMoraisAnsys]

LGTM, I would have preferred to use the faster uv command to be favoured, but I understand the issue you mentioned.

I think we have had issues in the past when using uv to create venv and that's why we moved to mainly using python in all our action. I can't remember the reason though :/ Could have been related to the use of --system in the past.

[RobPasMue]

LGTM, I would have preferred to use the faster uv command to be favoured, but I understand the issue you mentioned.

I think we have had issues in the past when using uv to create venv and that's why we moved to mainly using python in all our action. I can't remember the reason though :/ Could have been related to the use of --system in the past.

Yep - uv tends to create a virtual environment for you, and we ended up swtching to the --system flag. But it was a bit of pain if I remember properly to handle it consistently in our actions