Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Under v4, not specifying a python-version results in a failure to run #433

Closed
2 of 5 tasks
sirosen opened this issue Jun 13, 2022 · 4 comments
Closed
2 of 5 tasks
Labels
bug Something isn't working won't fix This will not be worked on

Comments

@sirosen
Copy link

sirosen commented Jun 13, 2022

Description:

In jobs which use the setup-python action without specifying a version, the change in #336 (python-version-file) causes a failure.
There's no value for python-version, so it attempts to read python-version-file with the default value. Because that file does not exist, the action fails.

Action version:

v4

Platform:

  • Ubuntu
  • macOS
  • Windows

(Probably impacts all, I haven't tested.)

Runner type:

  • Hosted
  • Self-hosted

(Again, presumably impacts both.)

Tools version:
N/A

Repro steps:
A job like this should reproduce:

jobs:
  repro-python-version-bug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
      - run: python -V

In case it does not, here's one of my original jobs:

jobs:
  pylint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
      - run: python -m pip install -U tox
      - run: tox -e pylint

Expected behavior:

The action should install one of the currently supported cpython versions.
For a job like this, the user is stating that they don't care which version is used, so long as it's a current version.

Actual behavior:

Crashfail with this message:

> Run actions/setup-python@v4
Error: The specified python version file at: /home/runner/work/globus-sdk-python/globus-sdk-python/.python-version does not exist

Quick fix for future readers

If you're reading this and not sure how to get the old behavior, change any job like so

 jobs:
   foo-job:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v3
       - uses: actions/setup-python@v4
+        with:
+          python-version: '3.x'
       - run: python -V

I recommend doing this over creating a .python-version file if you are not already using one. .python-version is used by pyenv, so putting 3.x into it would not be appropriate. You'll get errors like:

pyenv: version `3.x' is not installed (set by /.../.python-version)

@sirosen
Copy link
Author

sirosen commented Jun 13, 2022

When I filed this, I didn't read the full thread in #336 -- I went straight to reading the source. It looks from this comment like the change is intentional, and meant to harmonize with the setup-node action which requires that a version be specified.

Feel free to close as a wontfix if the maintainers think this is best. But for the record, I don't agree with this behavior.
I think 3.x as a default makes a ton of sense. The logic that "the action should be consistent with setup-node" makes some sense, but the languages and ecosystems are different: "the action should be different to accord with the differences between languages" seems an equally reasonable argument.

@dmitry-shibanov
Copy link
Contributor

Hello @sirosen. Thank you for your response. As you mentioned the current behaviour is expected one. For now we're not planning to change it. If we have any, we'll ping you. For now I'm going to close the issue.

@powderluv
Copy link

This does seem to break if you have a matrix build

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}
        cache: 'pip'
        cache-dependency-path: |
          **/requirements-importer.txt
          **/requirements.txt

@IvanZosimov
Copy link
Contributor

Hi, @powderluv 👋 ! I checked your case out and on my side, it works as usual. Please check this part of the documentation one more time. If this problem will appear again, please, create a new bug issue with a broader explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working won't fix This will not be worked on
Projects
None yet
Development

No branches or pull requests

4 participants