setup-python: Unhelpful error message related to unresolvable python version

Is there any reason why it can’t just default to the previous behavior when no python-version is provided and the .python-version file does not exist?

I see myself touching a lot of repositories to get this merged otherwise since i tend to just use the latest version provided by the action when i’m using it in the context of having to run some generic python tooling rather than working on an actual python project.

Would the recommended solution be to just use the system python that is provided by the runner?

Regardless of whether the semantics get brought back to v3, having a clearer error message about needing to specify one of python-version or python-version-file would help.

The official way to specify Python version is using pyproject.toml.

Thank you for your suggestions, @scop and @abitrolly ❤️ They really make sense, so we will try to make documentation and change logs clearer.

IMO, it would have been better to update setup-ruby to match setup-node and setup-python, rather than remove something useful (especially for beginners) from setup-python. Also setup-ruby was moved to ruby/setup-ruby, so it’s not even in actions/ anymore.

Also, it should be pointed out that .ruby-version is for rbenv, which is a very standard and common way to configure multiple Ruby’s - I use it on all my Ruby projects. While .python-version is from pyenv, which is a fork of rbenv for Python and much less of a standard; it is not properly supported by many tools like CMake, nox, tox, etc. I’ve personally only used it to compile beta versions once in a while, and I work on dozens of Python projects. I believe far more people use Conda in Python, which gets the Python version very differently. And there are other active experiments in multiple Python support. Supporting it is fine, but forcing it is not ideal.

I realized that setting python-version: "3.x" or ">=3.7" does at least remove the need to update the Python version once a year - if a default is not going to be re-added, then I can start updating my projects, examples, cookiecutter, and tutorials to use that.

The closest I’ve found to specifying latest so far is using 3.x

Perhaps somewhat cosmetic as far as the real world effects go, but note that per the usage docs, this supports “SemVer’s version range syntax”, which I guess means https://docs.npmjs.com/cli/v6/using-npm/semver#ranges. In that sense, one might want to use something like >=3.6 if there’s a lower bound and the intent is that not all 3.x versions are fine. And it would, for better or for worse, probably also mean that major versions > 3 (if they ever materialize) would match.

I’ve got lots of repositories with things like:

  steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-python@v3
    - uses: pre-commit/action@v3.0.0 # or some other one line run here

(and tutorials, etc). All of them will have to have a manual version added, that now needs to be updated yearly. It does seem like a default to fall back on “latest” if the version file isn’t present like v1-v3 would be really nice if possible! These repo’s don’t have a single Python “version” that should be locked by a file, it’s just needed to do a bit of Python for style, updates, etc. The regular CI jobs have the normal matrix of versions. Adding the .python-version is great, but losing the ability to run this in a single line and getting the latest Python seems like a downgrade. (Maybe there’s some technical reason I couldn’t find?) (Also, there doesn’t seem to be a way to specify latest at all - #300).

Is there any reason why it can’t just default to the previous behavior when no python-version is provided and the .python-version file does not exist?

I dont see a clear reason in the changelog. I agree with the proposed behaviour. This quite big breaking change is unnecessary/avoidable.

The latest stable python was always the default, the user has the ability to choose if they want a specific version. Plus a reason to not go forward with this, is the fact that dependabot doesn’t update to the latest version of python defined in the workflow, only the action, meaning pinning vulnerable tags is going to be more common.