Refactor setupPython to use uv python pin & venv setup

[Julfried]

This PR attempts to fix the issue where setup-uv does not correctly set up the Python version when pyproject.toml is specified and Python should be automatically determined from this file. As described in #283.

This is achieved by:

• Using uv python pin to correctly pin Python versions
• Extracting the pinned version from .python-version to ensure UV_PYTHON is set before activating venv

Let me know what you think. Feedback is very welcome :)

Closes #283

[eifinger]

Thank you for the PR.

Unfortunately this issue is a bit tricky. In general we have to decide how much this action should actually do as the name suggest it sets up uv and not more. It currently already does setup a venv in some cases. So we have to decide what the default behavior should be for most users.

Please understand that it might take a while for me to fully engage in feedback as this has to be in combination with

• VIRTUAL_ENV is set to wrong directory when using pyproject-file config #251
• Flag for --system-site-packages when initializing venv #260
• Support working-directory in action configuration #271
• Support .python-version files as input to with python-version #211
• Enable creation of venv with existing python version #217

[Julfried]

No worries, I just wanted to give this a try and propose a solution for my use case. I completely understand that the scope of setup-uv needs to be carefully considered.

That said, I do believe that setting up and activating a Python environment based on the current project should be included—ideally as an optional feature that users can enable if needed. This would make setup-uv more flexible without changing its default behavior.

I’d be happy to discuss this further and extend the PR to cover more use cases if that aligns with your vision. Take your time, and thanks again for the feedback :)