actions / setup-python

Set up your GitHub Actions workflow with a specific version of Python

setup-python

This action provides the following functionality for GitHub Actions users:

• Installing a version of Python or PyPy and (by default) adding it to the PATH
• Optionally caching dependencies for pip, pipenv and poetry
• Registering problem matchers for error output

Basic usage

See action.yml

Python

steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
  with:
    python-version: '3.10' 
- run: python my_script.py

PyPy

steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 
  with:
    python-version: 'pypy3.9' 
- run: python my_script.py

GraalPy

steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5 
  with:
    python-version: 'graalpy-22.3' 
- run: python my_script.py

The python-version input is optional. If not supplied, the action will try to resolve the version from the default .python-version file. If the .python-version file doesn't exist Python or PyPy version from the PATH will be used. The default version of Python or PyPy in PATH varies between runners and can be changed unexpectedly so we recommend always setting Python version explicitly using the python-version or python-version-file inputs.

The action will first check the local tool cache for a semver match. If unable to find a specific version in the tool cache, the action will attempt to download a version of Python from GitHub Releases and for PyPy from the official PyPy's dist.

For information regarding locally cached versions of Python or PyPy on GitHub hosted runners, check out GitHub Actions Runner Images.

Supported version syntax

The python-version input supports the Semantic Versioning Specification and some special version notations (e.g. semver ranges, x.y-dev syntax, etc.), for detailed examples please refer to the section: Using python-version input of the Advanced usage guide.

Supported architectures

Using architecture input it is possible to specify the required Python or PyPy interpreter architecture: x86 or x64. If the input is not specified the architecture defaults to x64.

Caching packages dependencies

The action has built-in functionality for caching and restoring dependencies. It uses toolkit/cache under the hood for caching dependencies but requires less configuration settings. Supported package managers are pip, pipenv and poetry. The cache input is optional, and caching is turned off by default.

The action defaults to searching for a dependency file (requirements.txt or pyproject.toml for pip, Pipfile.lock for pipenv or poetry.lock for poetry) in the repository, and uses its hash as a part of the cache key. Input cache-dependency-path is used for cases when multiple dependency files are used, they are located in different subdirectories or different files for the hash that want to be used.

• For pip, the action will cache the global cache directory
• For pipenv, the action will cache virtualenv directory
• For poetry, the action will cache virtualenv directories -- one for each poetry project found

Caching pip dependencies:

steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
  with:
    python-version: '3.9'
    cache: 'pip' # caching pip dependencies
- run: pip install -r requirements.txt

Note: Restored cache will not be used if the requirements.txt file is not updated for a long time and a newer version of the dependency is available which can lead to an increase in total build time.

The requirements file format allows for specifying dependency versions using logical operators (for example chardet>=3.0.4) or specifying dependencies without any versions. In this case the pip install -r requirements.txt command will always try to install the latest available package version. To be sure that the cache will be used, please stick to a specific dependency version and update it manually if necessary.

See examples of using cache and cache-dependency-path for pipenv and poetry in the section: Caching packages of the Advanced usage guide.

Advanced usage

• Using the python-version input
• Using the python-version-file input
• Check latest version
• Caching packages
• Outputs and environment variables
• Available versions of Python, PyPy and GraalPy
• Hosted tool cache
• Using setup-python with a self-hosted runner
• Using setup-python on GHES
• Allow pre-releases

License

The scripts and documentation in this project are released under the MIT License.

Contributions

Contributions are welcome! See our Contributor's Guide.

setup-python's Issues

Python process exiting abruptly on windows-2019

I have been porting several project test suites over to GitHub Actions, and I encountered a strange behaviour on the windows-2019 image: running a trivial unittest-based test suite, Python exits with an exit code of 1 after successfully running just a single test. This behaviour does not occur on Linux, OS X or windows-2016.

I have put together a minimal project (no dependencies, a trivial module which just defines __version__, and two trivial tests) with which systematically triggers the issue:

https://github.com/aiortc/unittest-ga

As you can see the test suite:

• passes for all Python versions on OS X / Linux / Windows 2016
• fails for all Python versions on Windows 2019

The error looks like:

test_first (tests.test_me.MyTest) ... ok
##[error]Process completed with exit code 1.

PyPy3 doesn't create envs properly on Windows, 7.3.1 would fix

pytest-dev/pytest-twisted#85
https://foss.heptapod.net/pypy/pypy/issues/3155

In short, PyPy3 has used bin/ everywhere instead of doing Scripts/ on Windows. While I wish _everything_ was consistently bin/, ... it isn't. PyPy3 7.3.1 corrects this. Thanks for updating when you get a chance.

To help searches lead here, here's an example warning (to be an error at somepoint) from tox.

https://github.com/pytest-dev/pytest-twisted/pull/85/checks?check_run_id=459428253#step:5:15

WARNING: test command found but not installed in testenv
  cmd: C:\hostedtoolcache\windows\PyPy\3.6.9\x86\python.EXE
  env: D:\a\pytest-twisted\pytest-twisted\.tox\pypy3-defaultreactor
Maybe you forgot to specify a dependency? See also the whitelist_externals envconfig setting.

master

Thank you 🙇‍♀ for wanting to create an issue in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue relates to code in this repository.

• If you have found a security issue please submit it here
• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

If your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.

Escaped newlines in error message

I provided an invalid version and architecture to the setup-python action:

    - name: 'Select Python version'
      uses: actions/setup-python@master
      with:
        version: $PYTHON_VERSION
        architecture: $PYTHON_ARCH

(I was attempting to make variable expansion happen.) The error message was surprising, with what appear to be escaped \r and \n:

##[error]Version $PYTHON_VERSION with arch $PYTHON_ARCH not found%0D%0AAvailable versions:%0D%0A%0D%0A

I would expect either actual newlines or some other type of whitespace, not %0D%0A.

One version of Python 3.7 is no longer available on all OSes

Until recently, I have been using Python 3.7.4 for cross-platform testing. Now that 3.7.4 has been removed from the tool cache on Ubuntu, there is no longer a version of Python 3.7 available for cross-platform testing.

Here is a sample run:
https://github.com/starship/starship/runs/282675872

Use recommended release strategy

We should be using the release strategy specified by https://github.com/actions/toolkit/blob/master/docs/action-versioning.md#recommendations

To get there, we need to:

1. Create a releases/v1 branch and move the v1 tag and future releases there
2. Warn that we will deprecate the master branch and that you should attach to v1 instead. We will support master in a warned but deprecated state for ~1 month.
3. Switch the warning to an error on master. Remove node_modules from the master branch. We will stay in this state for ~1 month.
4. Remove the error on master.

During steps 2 and 3, we need to be extra careful to not check the warning/error into the releases branch.

[BUG] Setting up pypy2/pypy3 on macOS is inconsistent with Ubuntu

runs-on: macOS-latest
...
steps:
- uses: actions/checkout@master
- name: Set up Python ${{ matrix.python-version }}
  uses: actions/[email protected]
  with:
    python-version: pypy3  # or pypy2
- name: Log Python version
  run: >-
    python --version
- name: Log Python location
  run: >-
    which python

Output for Ubuntu (with pypy3 / https://github.com/pypa/setuptools/pull/1967/checks?check_run_id=389069197#step:4:1):

$ python --version
Python 3.6.9 (5da45ced70e5, Oct 09 2019, 19:12:54)
[PyPy 7.2.0 with GCC 6.2.0 20160901]
$ which python
/opt/hostedtoolcache/PyPy/3.6.9/x64/bin/python

Output for macOS (with pypy3 / https://github.com/pypa/setuptools/pull/1967/checks?check_run_id=389069238#step:4:1):

$ python --version
Python 2.7.17
$ which python
/usr/local/bin/python

Output for Ubuntu (with pypy2 / https://github.com/pypa/setuptools/pull/1967/checks?check_run_id=389069417#step:4:1):

$ python --version
Python 2.7.13 (8cdda8b8cdb8, Apr 14 2019, 14:06:44)
[PyPy 7.1.1 with GCC 6.2.0 20160901]
$ which python
/opt/hostedtoolcache/PyPy/2.7.13/x64/bin/python

Output for macOS (with pypy2 / https://github.com/pypa/setuptools/pull/1967/checks?check_run_id=389069522#step:4:1):

$ python --version
Python 2.7.17
$ which python
/usr/local/bin/python

Document how to configure setup-python on a self hosted runner

GitHub hosted runners have a tools cache that setup-python relies on. Self-hosted runners do not have this tools cache downloaded/setup so setup-python will not work.

If the tools cache is downloaded/setup on a self-hosted runner, setup-python can be used.

Virtualenv Issues Under Windows

I seem to be having problems, under windows, when using nox which creates a virtualenv based off of the available Python to install dependencies into it and run tests against it.

The workflow test run can be seen here

nox > Command c:\hostedtoolcache\windows\python\2.7.16\x64\python.exe -m virtualenv D:\a\pip-tools-compile-impersonate\pip-tools-compile-impersonate\.nox\tests-2-7 -p python2.7 failed with exit code 100:
Traceback (most recent call last):

  File "D:/a/pip-tools-compile-impersonate/pip-tools-compile-impersonate/.nox/tests-2-7/lib/python2.7/site.py", line 769, in <module>

    main()

  File "D:/a/pip-tools-compile-impersonate/pip-tools-compile-impersonate/.nox/tests-2-7/lib/python2.7/site.py", line 757, in main

    aliasmbcs()

  File "D:/a/pip-tools-compile-impersonate/pip-tools-compile-impersonate/.nox/tests-2-7/lib/python2.7/site.py", line 513, in aliasmbcs

    import locale, codecs

  File "D:\a\pip-tools-compile-impersonate\pip-tools-compile-impersonate\.nox\tests-2-7\lib\python2.7/locale.py", line 19, in <module>

    import functools

ImportError: No module named functools

Already using interpreter C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/opt/bin/python2.7.exe

  No LICENSE.txt / LICENSE found in source


New python executable in D:\a\pip-tools-compile-impersonate\pip-tools-compile-impersonate\.nox\tests-2-7\Scripts\python2.7.exe

Also creating executable in D:\a\pip-tools-compile-impersonate\pip-tools-compile-impersonate\.nox\tests-2-7\Scripts\python.exe

ERROR: The executable D:\a\pip-tools-compile-impersonate\pip-tools-compile-impersonate\.nox\tests-2-7\Scripts\python2.7.exe is not functioning

ERROR: It thinks sys.prefix is u'd:\\a\\pip-tools-compile-impersonate\\pip-tools-compile-impersonate' (should be u'd:\\a\\pip-tools-compile-impersonate\\pip-tools-compile-impersonate\\.nox\\tests-2-7')

ERROR: virtualenv is not compatible with this system or executable

Note: some Windows users have reported this error when they installed Python for "Only this user" or have multiple versions of Python installed. Copying the appropriate PythonXX.dll to the virtualenv Scripts/ directory may fix this problem.

Running virtualenv with interpreter C:\ProgramData\Chocolatey\bin\python2.7.exe

nox > Session tests-2.7 failed.

Version 3.8.1 with arch x64 not found

It seems that with updates we remove support for earlier python versions

 Set up Python 3.8.11s
3.8.2 (x64)
Run actions/setup-python@v1
##[error]Version 3.8.1 with arch x64 not found
Available versions:

2.7.17 (x64)
3.5.9 (x64)
3.6.10 (x64)
3.7.6 (x64)
3.8.2 (x64)

Would it be possible to maintain support for 3.8.1 or at least give a warning so we can do updates at our own pace?

pythonLocation value inconsistent between CPython and PyPy

The value of pythonLocation is inconsistent between CPython and PyPy

On both pypy2 and pypy3 the bin path segment is included in the pythonLocation variable:

pypy3 pythonLocation

/opt/hostedtoolcache/PyPy/3.6.9/x64/bin

pypy2 pythonLocation

/opt/hostedtoolcache/PyPy/2.7.13/x64/bin

But for the CPython versions it isn't.
3.6 pythonLocation

/opt/hostedtoolcache/Python/3.6.10/x64

2.7 pythonLocation

/opt/hostedtoolcache/Python/2.7.17/x64

I would expect the PyPy versions to be consistent with CPython builds

Missing ssl module in macos-latest (Python 3.8)

We are using setup-python in our macos CI workflow: https://github.com/lektor/lektor/blob/master/.github/workflows/ci.yml#L304

Since a few days back our runs break on Python 3.8: https://github.com/lektor/lektor/runs/598104831

This is the stdout from when we do pip install -e .

Run python -m pip install --editable .[test]
  python -m pip install --editable .[test]
  python -m pip install codecov
  shell: /bin/bash -e {0}
  env:
    CI: true
    PYTHON_VERSION: 3.8
    pythonLocation: /Users/runner/hostedtoolcache/Python/3.8.2/x64
WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Obtaining file:///Users/runner/runners/2.169.0/work/lektor/lektor
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError("Can't connect to HTTPS URL because the SSL module is not available.")': /simple/babel/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError("Can't connect to HTTPS URL because the SSL module is not available.")': /simple/babel/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError("Can't connect to HTTPS URL because the SSL module is not available.")': /simple/babel/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError("Can't connect to HTTPS URL because the SSL module is not available.")': /simple/babel/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError("Can't connect to HTTPS URL because the SSL module is not available.")': /simple/babel/
Could not fetch URL https://pypi.org/simple/babel/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/babel/ (Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available.")) - skipping
ERROR: Could not find a version that satisfies the requirement Babel (from Lektor==3.1.3) (from versions: none)
ERROR: No matching distribution found for Babel (from Lektor==3.1.3)
WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/pip/ (Caused by SSLError("Can't connect to HTTPS URL because the SSL module is not available.")) - skipping
##[error]Process completed with exit code 1.

It seems to have broken within the last 7 days or so.

Python Framework build for macOS?

Sorry, I am not 100% sure this is the correct place for my question/issue.

The Python build offered by setup-python on macOS is not a so-called "Framework build". This prohibits certain usages, such as building native Mac applications with Python.

I can use the supplied Python (3.7 in my case) to run my test suite, but to build my application, I will either have to resort to homebrew (ugh) or download an installer from python.org, which, while slightly less ugh will make my build time a lot longer, unnecessarily increasing my resource usage.

Here is some useful info: https://stackoverflow.com/questions/1444543/differences-between-framework-and-non-framework-builds-of-python-on-mac-os-x

Is there a chance GitHub actions could provide a Framework build of Python in the future?

windows: Pre-installed mingw python2.7.exe causes issues

When trying use this action I had some trouble with the preexisting python2.7.exe that exists in the PATH. Specifically I ran in two separate issues:

1. cmake can end up choosing mingw python2.7.exe over the setup-python configured python.exe. For example if you have find_package(PythonInterp 2.7 REQUIRED) in your cmake file then cmake will always prefer the explicit python2.7.exe in the PATH.

2. The mingw version of python fails when argv[1] contained withing directory separators. In this case it fails to set the initial python path correctly. This causes issues for subprocesses too, for example if you construct the name of a python script with with os.path.join and then try to run it with sys.executable is can file. I constructed a simple repo to demonstrate this problem:

https://github.com/sbc100/python-mingw-fail/runs/316815593

As you can see the python2.7 with windows path step fails because sys.path[0] is not set correctly.

Possible solutions:

1. Remove mingw's python2.7.exe from $PATH. This would be ideal for my use case.
2. Add python2.7.exe to C:\hostedtoolcache\windows\Python\2.7.16\x64
3. Fix this seeming bug in mingw python.

(3) is actually not that great of solution because really the point of using setup-python is that it should be in control of the version of python that gets uses, and using the mingw python seems wrong.

Unexpected response code from remote provider InternalServerError

In this ticket, the users reported when they use the setup-python action in their workflows, sometimes they will get the errors like as the following:

Check warning on line 1 in .github

@@github-actions
github-actions / Python 3.5 on macos-latest

.github#L1
There was a failure in sending the provision message: Unexpected response code from remote provider InternalServerErro

 Check failure on line 1 in .github

@github-actions
github-actions/ Python 3.5 on macos-latest

.github#L1
Provisioning request delayed or failed to send 5 time(s). This is over the limit of 3 time(s).

Feature proposal: Integrate dependency support

I think a most users of this action run an "install dependencies" step immediately after. I think it would improve the developer experience if the "install dependencies" step was integrated into this action.

Current workflow:

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt

Option 1: Support installing packages with pip

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}
        pip-install: -r requirements.txt

        # or if you use a different package manager...
        # pip-install: pipenv
    # - name: Install dependencies
      # run: pipenv install

Option 2: Add full support for all package managers

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}
        # Pip
        package-manager: pip
        package-manager-args: -r requirements.txt
        # Pipenv
        package-manager: pipenv
        package-manager-args: --pre --dev --deploy
        # Poetry
        package-manager: poetry
        package-manager-args: --no-dev

What do you think? Option 1 is much smaller in scope than option 2, but I think both would be low maintenance (Python has a lot of package managers, but not that many).

Matrix variable not formatting into step name

Actual result

I'm seeing this as the name for a step:

 ${{ format('Set up Python {0}', matrix.python-version) }}

https://github.com/hugovk/pypistats/runs/208658458

Expected result

I expect to see "Set up Python 3.7".

Config

I'm using this workflow config:

name: Lint

on: [push, pull_request]

jobs:
  build:

    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.7]

    steps:
    - uses: actions/checkout@v1

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        python -m pip install --upgrade tox

    - name: Lint
      run: tox -e lint

Am I doing something wrong? Can ${{ matrix.python-version }} be used in step names?

An example in the README shows a similar var in the job name, and I've confirmed that works:

jobs:
  build:
    runs-on: ubuntu-16.04
    strategy:
      matrix:
        python: [ '2.x', '3.x', 'pypy3' ]
    name: Python ${{ matrix.python }} sample
    steps:
      - uses: actions/checkout@master
      - name: Setup python
        uses: actions/setup-python@v1
        with:
          python-version: ${{ matrix.python }}
          architecture: x64
      - run: python my_script.py

Python 2 compiled without wide unicode support

Hi there 👋

Not sure if this is the right forum for this (maybe a GitHub Actions VM image issue), but the version of Python 2.7 when running in a VM is not compiled with wide unicode support (--enable-unicode=ucs4 during the configure step).

This seems the same on both ubuntu-18.04 and ubuntu-16.04 images.

Python installed from the Ubuntu repos does include wide unicode support, and so do the official Python Docker images.

This has the subtle effect that you can only install wheels built without wide unicode support (cp27m packages), rather than the more common wide unicode support (cp27mu). Some popular packages (e.g. pandas) only build wheels with wide unicode support and so will fail to install (for various reasons) on Python 2.7 in a GitHub Actions VM. Here is some code showing this.

Support Anaconda Python

I would like to use GitHub Actions to build a Conda package. I know that the environments contain Anaconda Python but it would be great if we could select Anaconda Python versions using the actions in this repository.

PyPy3 ImportError lzma

platform linux -- Python 3.6.9[pypy-7.3.0-final]

......
lzma = import('lzma')
/opt/hostedtoolcache/PyPy/3.6.9/x64/lib-python/3/lzma.py:27: in
from _lzma import *

---

import threading
import functools
import collections
import weakref
import sys
import io
import __pypy__

from _lzma_cffi import ffi, lib as m
E ImportError: /opt/hostedtoolcache/PyPy/3.6.9/x64/lib_pypy/_lzma_cffi.pypy36-pp73-x86_64-linux-gnu.so: undefined symbol: lzma_index_stream_padding

/opt/hostedtoolcache/PyPy/3.6.9/x64/lib_pypy/_lzma.py:15: ImportError

How to find available versions?

I'm keen on trying GitHub Actions with a few Python projects I have that I support a broad variety of older releases.

I saw the readme mentioned 2.x, 3.x and PyPy, but it wasn't clear what versions of Python are supported on what virtual environments?

In the past dealing with Travis it has always been really opaque and a source of annoyance to have to "guess" and create commits to trigger CI runs, just to try and figure out what versions I can actually target.

Having a list in the readme would be 👍.

Shell Python not updating.

I'm not sure if this is outside the intended scope of this action, but the updated Python version does not replace the Python used by the shell: python option in a step. This makes it so in-line scripts in my steps run on 2.7 instead of the intended 3.x.

Here are some steps I did to confirm the discrepancy:

    - run: python -c "import sys; print sys.version"
    - uses: actions/setup-python@v1
      with:
        python-version: '3.x'
        architecture: 'x64'
    - run: python -c "import sys; print(sys.version)"  
    - shell: python
      run: |    
        import sys
        print(sys.version)

The logs from running these 4 steps show the python 2.7.15 running the first step as expected, and 3.7.4 running the 3rd step as expected (since step 2 installs it), but surprisingly 2.7.15 is once again running the 4th step.

If this is intended behavior, that's fine, it just might be worth mentioning somewhere in the readme.md since this feels like an inconsistency to me.

Python 3.5.9 SIGABORTs

Python 3.5.9 running on GHA crashes with SIGABORT as visible in this workflow: https://github.com/tysonite/robotframework/runs/528709914?check_suite_focus=true#step:13:89

The output of Python process includes:

double free or corruption (!prev)

The freshly downloaded (and compiled) Python 3.5.9 from official web site does not crash on the same operation on Ubuntu 18.04.

Tool cache Python errors when run in a container

Is this expected behaviour when running inside a container? /opt/hostedtoolcache is volume mounted to /__t, so it seems like the intention is that tools in the cache can be used in a container.

on: push
jobs:
  pythonInContainer:
    runs-on: ubuntu-latest
    container:
      image: ubuntu:18.04
    steps:
      - uses: actions/setup-python@v1
        with:
          python-version: '3.8.x'
      - run: python --version

Release setup-python as an npm package

I have a Javascript action that executes Python. It would be great if I could add @actions/setup-python as a dependency and call it from my Javascript action.

In order to make it work for now I converted parts of this action into a setupPython function that I've included with my action. Below is a simplified snippet of what I'm doing now. Full source code here.

async function run() {
  try {
    const src = __dirname + "/src";

    // Setup Python from the tool cache
    setupPython("3.8.0", "x64");

    // Install requirements
    await exec.exec("pip", [
      "install",
      "--requirement",
      `${src}/requirements.txt`
    ]);

    // Execute python script
    await exec.exec("python", [`${src}/create-pull-request.py`]);
  } catch (error) {
    core.setFailed(error.message);
  }
}

Here is a python-action template that also demonstrates what I'm doing in the snippet above.

Why call Python from a Javascript action?
The reason I ended up doing this and not writing the whole action in Javascript requires a bit of history and explanation. I wrote the action during GitHub Actions beta v1 when it was just container actions. When Actions v2 arrived the choices were Javascript or Docker container actions. I want the action to be multi-platform and runnable on any virtual machine, so I have no choice but to wrap it with a Javascript action as I'm doing, or convert the whole action to Javascript.

Even if Docker container actions worked on all platforms I think I would still choose to wrap Python in Javascript like this. The two issues I don't like about container actions are:

• When using image: 'Dockerfile' it's slow because the image is built from scratch every time the workflow runs.
• When using image: 'docker://my-namespace/my-image:1.0.0' it cannot be forked easily because the reference to the public Docker image remains. Being able to fork GitHub actions is important for security conscious users.

Add full support for SQLite

Software that uses SQLite extensions such as Spatialite and RasterLite require Python versions with extension loading enabled in Python.

Currently, any code that uses Spatialite throws an error when enabling extension loading. Attempted Ubuntu and MacOS runners and the error is the same.

ERROR

AttributeError: 'sqlite3.Connection' object has no attribute 'enable_load_extension'

Stack trace

---

self = <aequilibrae.project.project.Project object at 0x1192b5750>
path_to_file = '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/test_file.sqlite'
new_project = True

def __init__(self, path_to_file: str, new_project=False):
    self.path_to_file = path_to_file
    self.parameters = Parameters().parameters
    if not os.path.isfile(path_to_file):
        if not new_project:
            raise FileNotFoundError(
                "Model does not exist. Check your path or use the new_project=True flag to create a new project"
            )
        else:
            self.__create_empty_project()
    else:
        self.conn = sqlite3.connect(self.path_to_file)

  self.conn.enable_load_extension(True)

E AttributeError: 'sqlite3.Connection' object has no attribute 'enable_load_extension'

aequilibrae/project/project.py:24: AttributeError

Support custom Python versions

My project requires Python 2.7.7 because it has to be compatible with a game that uses this version. It will be cool if the setup-python supports old versions. Now it doesn't:

##[error]Version 2.7.7 with arch x64 not found
Available versions:

2.7.16 (x64)
3.5.7 (x64)
3.6.9 (x64)
3.7.4 (x64)
##[error]Node run failed with exit code 1

So I have to add script to install it manually:

https://github.com/SerVB/TheRecentStatOfYou/blob/cc20ecf4e2f530feb219a9e28dfd7aea847ea6a6/.github/workflows/build.yml#L9-L21

Can you implement executing these lines if the version not in [2.7.16, 3.5.7, 3.6.9, 3.7.4]? My script will be much smaller!

List supported python versions in the README

^ It seems that when running ci that only the latest minor python version is supported not all patch versions, it might be useful to document that. Or, if I'm wrong documenting the specific supported versions could also help!

Show installed version in action log

I use actions/setup-python@v1 in my project with a version constraint like this python-version: '3.x'. In the actions log i can not see the actually installed version, like it is the case for actions/[email protected] where I also use a version constraint. It would be nice if we could extend the output.

Output for this action:

Run actions/setup-python@v1
  with:
    python-version: 3.x
    architecture: x64
Added matchers: 'python'. Problem matchers scan action output for known warning or error strings and report these inline.

Output for setup-elixir:

Run actions/[email protected]
  with:
    otp-version: 22.x
    elixir-version: 1.9.x
    install-hex: true
    install-rebar: true
Installing OTP 22.2.1
Installing Elixir v1.9.4 <--- this line

Python on macOS is built against 10.14 SDK

It looks like the Python interpreters on macOS are compiled with macOS 10.14 as deployment target. They should rather be built against the oldest supported macOS SDK so that no errors are encountered when a program built against an older SDK is linked with the Python libraries. (Ideally we'd like to build against the 10.9 SDK, but unfortunately it is not supported; it will have to be 10.12, I suppose.)

Python 2.7 setup runtime unable to successfully install packages

Hi. In a recent PR on a project I work on I tried to move testing of Python 2.7 from Travis CI to GitHub Actions. In doing so I found that the Python 2.7 runtime setup by setup-python has the tests fail as it is unable to install TensorFlow during the the Install dependencies step.

I've made a minimal failing example in the following repo: test-setup-python-action. Here I show that if I only have setup-python setup Python 3.6 and Python 3.7 runtimes the installation is able to succeed and the GitHub Action finishes. If I then also ask for setup-python to setup Python 2.7 it fails quickly. Unless I've misunderstood something about how setup-python works this seems to show that there is something about the Python 2.7 runtime that is setup which is causing installation issues. Additionally, I have checked that the installation with Python 2.7 works fine in the Python 2.7 Docker image.

I realize I'm simply reporting information rather then actually pointing to anything specific. If I can be of help in trying to fix this in any way please let me know, as my project would love to be able to fully move our testing to GitHub Actions.

Also, thanks for making the setup-python action! It is great!

cc @kratsg @lukasheinrich

Support IronPython/Jython

It would be nice to support IronPython/Jython as well.

Add Support for TK in provided python instances

Hello,

A few people (myself included) have run into issues trying to run code that imports tkinter. It would be helpful if the provided python packages supported TK:

https://github.community/t5/GitHub-Actions/GitHub-Action-for-python-import-of-quot-tkinter-quot-fails/m-p/40644#M4305

Add support for in-development Python versions

When developing a Python library, it would be useful to know whether there are any incompatibilities with the upcoming release. So it would be useful to be able to include the latest alpha or beta release in the version matrix used to run my test suite (currently 3.8.0b4).

pipenv install fails with python 3.8.1 and on ubunut-latest 2.164.0

Describe the bug
pipenv fails on ubunut-latest '2.164.0'. The builds passed in '2.163.0'. The problem seems that it is unable to parse the python requirement version from the pipfile.

To Reproduce

    - name: Install dependencies
      run: |
        echo "check python version"
        python -V
        python -m pip install --upgrade pip
        python -m pip install pipenv

Expected behavior
Install pipenv version with python 3.8.1.

Runner Version and Platform

Version of your runner?

ubuntu-latest

    runs-on: ubuntu-latest
    steps:
    - name: Set up Python 3.8
      uses: actions/setup-python@v1
      with:
        python-version: "3.8.1"

What's not working?

Please include error messages and screenshots.

Job Log Output

Run echo "check python version"
check python version
Python 3.8.1
Requirement already up-to-date: pip in /opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages (19.3.1)
Collecting pipenv
  Downloading https://files.pythonhosted.org/packages/13/b4/3ffa55f77161cff9a5220f162670f7c5eb00df52e00939e203f601b0f579/pipenv-2018.11.26-py3-none-any.whl (5.2MB)
Requirement already satisfied: setuptools>=36.2.1 in /opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages (from pipenv) (41.2.0)
Collecting virtualenv
  Downloading https://files.pythonhosted.org/packages/05/f1/2e07e8ca50e047b9cc9ad56cf4291f4e041fa73207d000a095fe478abf84/virtualenv-16.7.9-py2.py3-none-any.whl (3.4MB)
Collecting virtualenv-clone>=0.2.5
  Downloading https://files.pythonhosted.org/packages/ba/f8/50c2b7dbc99e05fce5e5b9d9a31f37c988c99acd4e8dedd720b7b8d4011d/virtualenv_clone-0.5.3-py2.py3-none-any.whl
Requirement already satisfied: pip>=9.0.1 in /opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages (from pipenv) (19.3.1)
Collecting certifi
  Downloading https://files.pythonhosted.org/packages/b9/63/df50cac98ea0d5b006c55a399c3bf1db9da7b5a24de7890bc9cfd5dd9e99/certifi-2019.11.28-py2.py3-none-any.whl (156kB)
Installing collected packages: virtualenv, virtualenv-clone, certifi, pipenv

Successfully installed certifi-2019.11.28 pipenv-2018.11.26 virtualenv-16.7.9 virtualenv-clone-0.5.3
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.1/x64/bin/pipenv", line 8, in <module>
    sys.exit(cli())
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/cli/command.py", line 235, in install
    retcode = do_install(
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/core.py", line 1734, in do_install
    ensure_project(
  File "/opt/hostedtoolcache/Python/3.8.1/x64/lib/python3.8/site-packages/pipenv/core.py", line 584, in ensure_project
    "{0}: Your Pipfile requires {1} {2}, "
TypeError: __str__ returned non-string (type NoneType)
##[error]Process completed with exit code 1.

It seems to have trouble getting the python version from the system.

https://github.com/pypa/pipenv/blob/master/pipenv/core.py#L589

v1 tag missing for a while?

Was the v1 tag deleted for a bit? We had trouble downloading the action tarball yesterday. What version should we tie ourselves to?

No versions of Python available on macOS-latest?

For example: https://github.com/thejohnfreeman/project-template-python/pull/6/checks?check_run_id=198328776#step:3:6

Document pythonLocation

There does not seem to be any documentation referring to pythonLocation.

Add Python 3.8 support

Python 3.8.0 was released yesterday, 2019-10-14:

• https://discuss.python.org/t/python-3-8-0-is-now-available/2478

Please could you also add support in GitHub Actions for Python 3.8? Thank you!

Also requested at GitHub Community Forum:

• https://github.community/t5/GitHub-Actions/Add-Python-3-8-support/td-p/34759

Thank you!

Turn off error matchers?

As discussed at https://github.community/t5/GitHub-Actions/Possible-to-turn-off-error-matchers/td-p/31070 how can we get rid of these confusing messages?

There is a message in https://github.com/ddelange/pipgrip/commit/74f5a858bd535a90f48e5486dad7cbc0472daa7c/checks?check_suite_id=393749770 that says:

Run actions/setup-python@v1
Added matchers: 'python'. Problem matchers scan action output for known warning or
error strings and report these inline.

Thank you 🙇‍♀ for wanting to create an issue in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue relates to code in this repository.

• If you have found a security issue please submit it here
• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

If your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.

PyPy3 runs CPython 2 instead

Config

Part of .github/workflows/test.yml:

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}

    - name: Build system information
      run: |
        python .github/workflows/system-info.py

.github/workflows/system-info.py:

"""
Print out some handy system info like Travis CI does.

This sort of info is missing from GitHub Actions.

Requested here:
https://github.com/actions/virtual-environments/issues/79
"""
import os
import platform
import sys

print("Build system information")
print()

print("sys.version\t\t", sys.version.split("\n"))
print("os.name\t\t\t", os.name)
print("sys.platform\t\t", sys.platform)
print("platform.system()\t", platform.system())
print("platform.machine()\t", platform.machine())
print("platform.platform()\t", platform.platform())
print("platform.version()\t", platform.version())
print("platform.uname()\t", platform.uname())
if sys.platform == "darwin":
    print("platform.mac_ver()\t", platform.mac_ver())

Expected result

When:

• matrix-os is "macOS-latest"
• matrix.python-version is "pypy3"

Runs with PyPy3, as it did two days ago.

https://github.com/python-pillow/Pillow/runs/379447500

Actual result

When:

• matrix-os is "macOS-latest"
• matrix.python-version is "pypy3"

Runs with CPython 2, since yesterday, and fails.

Works as expected on Linux/PyPy3, Linux/CPython and macOS/CPython.

https://github.com/python-pillow/Pillow/runs/380647169

More info

Here's a diff of the logs of the [last passing build (PyPy3)] build](https://github.com/python-pillow/Pillow/runs/379447500) and first failing build (CPython 2):

Also

On macOS/PyPy3, python is CPython 2.7.17 and python3 is CPython 3.7.6.

On Linux/PyPy3, Linux/CPython, macOS/CPython, both python and python3 pointing to the same, correct version.

https://github.com/hugovk/Pillow/runs/383338343 shows output of:

    - name: Build system information
      run: |
        python --version
        python .github/workflows/system-info.py
        python3 --version
        python3 .github/workflows/system-info.py

---

Downstream issue: python-pillow/Pillow#4350

Document how to evade a specific version

It'd be great if the documentation covered specifically how to "evade" a given version -- i.e., how does one use this action to provision 2.7 and 3.3, but if the 3.4 provisioning is broken for whatever reason, how does one drop down a level and provision that one themselves.

(Obviously related to #16, where now I'm trying to figure out how I use this for everything but the combination of pypy3-on-windows, where I have to figure out how to manually get the right version myself)

Offer Python Latest (nightly master trunk build)

One of the features I love most about TravisCI is the ability to build my projects CI with top of Trunk Python (master branch). This allows me to know about deprecations etc. coming very early and have time to work on the fixes sooner.

Can actions look at supporting building a Trunk version nightly? Here is an example usage with Travis: https://github.com/facebookincubator/ptr/blob/master/.travis.yml#L16

Haven't dug in deep, but would also love to have the ability for this build to be able to fail and not flag CI failure, like the Travis config above does.

Thanks.

Add options for Python with Precompiled stdlib and debug binaries

I wonder if it would be viable to give a parameter for advanced usages in this action. For example I need this exact setup as in the title.

LINK : fatal error LNK1104: cannot open file 'python38_d.lib'
We need a Python interpreter that is shipped with libpython and header files.

Since ever I need to download the Python setup and deinstall with it the same version from the CI just to install with the following command:

setup.exe /quiet Include_debug=1 Include_dev=1 Include_lib=1 Include_pip=1 PrependPath=1 CompileAll=1 InstallAllUsers=1 TargetDir=<workspace-dir>\Python38-x64-dbg\

Would be really cool to see such options here as well, so I (we?) can easily setup the Python installation for a build matrix for example.

cc: actions/runner-images#786
cc: #85
cc: actions/python-versions#16

Effect of python 2 sunset on setup-python

From the blogpost announcement:
https://github.blog/changelog/2020-02-27-github-actions-breaking-change-python-2-being-removed-from-all-virtual-environments/

If you're using setup-python, please update your workflows to use Python versions 3.x.

which reads like "python 2 won't be supported by setup-python", is this the case?
If so, what workarounds are there?
Perhaps it's worth updating the README to reflect this.

Could not make it work with self-hosted MacOs

The action doesn't seem to work on self-hosted MacOs. Here is the error log:

I tried both:

- uses: actions/setup-python@v1
with:
          python-version: "3.8.2"

and without specifying the version:

- uses: actions/setup-python@v1

The documentation states that the latest version is 3.8.2 and it has built for x64. As you see in the picture, there is no Available versions: in the logs.

PyPy3 version is quite old

The version of PyPy3 that's provisioned is quite old (and buggy -- e.g. PyYAML doesn't even seem to work on it on Windows -- https://github.com/Julian/github-actions-test/runs/205309060#step:5:29 )

The current version is a Python 3.6 (https://www.pypy.org/download.html#building-from-source) and a lot more stable (I'm not sure whether it fixes the YAML issue above but going to check, it probably should).

(Not sure whether the PyPy2 is also out of date, I can't tell yet how to check its version without writing a build to just output it -- also not sure if this is something I can fix myself and send a PR for but if I do see how to do that will be sure to.)

Also look at `$RUNNER_TOOL_CACHE` for finding the tool cache directory

See this code: https://github.com/actions/runner/blob/6bec1e3bb832aad26f4ad5b64759a8e4d468df24/src/Runner.Common/HostContext.cs#L233

The runner prefers RUNNER_TOOL_CACHE and then falls back to RUNNER_TOOLSDIRECTORY. setup-python only uses the latter:

setup-python/src/find-python.ts

Line 6 in 9ac7308

let cacheDirectory = process.env['RUNNER_TOOLSDIRECTORY'] || '';

• Update the code
• Update the self-hosted guidance

Add pypy-nightly and pypy3-nightly

Besides #16 for the latest releases, it would be nice to be able to build against the nightly versions of PyPy as well: http://buildbot.pypy.org/nightly/trunk/

pypy-c-jit-latest-linux64.tar.bz2 | 25M | 2019-08-28 |   |  
-- | -- | -- | -- | --
pypy-c-jit-latest-linux.tar.bz2 | 24M | 2019-08-28 |   |  
pypy-c-jit-latest-aarch64.tar.bz2 | 23M | 2019-08-28 |   |  
pypy-c-jit-latest-win32.zip | 27M | 2019-08-28 |   |  
pypy-c-jit-latest-s390x.tar.bz2 | 25M | 2019-08-28 |   |  
pypy-c-jit-latest-linux-armhf-raspbian.tar.bz2 | 23M | 2018-12-01 |   |  
pypy-c-jit-latest-linux-armel.tar.bz2 | 23M | 2018-11-21 |   |  
pypy-c-jit-latest-osx64.tar.bz2 | 18M | 2019-08-28 |

test

Thank you 🙇‍♀ for wanting to create an issue in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue relates to code in this repository.

• If you have found a security issue please submit it here
• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

If your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.