actions / setup-python Goto Github PK
View Code? Open in Web Editor NEWSet up your GitHub Actions workflow with a specific version of Python
License: MIT License
Set up your GitHub Actions workflow with a specific version of Python
License: MIT License
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 |
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
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.
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!
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.
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
.
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
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
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.
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).
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
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.
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.
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:
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!
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 your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.
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.)
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.
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())
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
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
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):
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
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).
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
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
It would be nice to support IronPython/Jython as well.
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.
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:
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.
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:
python2.7.exe
from $PATH
. This would be ideal for my use case.python2.7.exe
to C:\hostedtoolcache\windows\Python\2.7.16\x64
(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.
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.
Python 3.8.0 was released yesterday, 2019-10-14:
Please could you also add support in GitHub Actions for Python 3.8? Thank you!
Also requested at GitHub Community Forum:
Thank you!
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.)
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 👍.
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:
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
I expect to see "Set up Python 3.7".
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
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 your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.
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
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.
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.
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"
Please include error messages and screenshots.
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
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:
releases/v1
branch and move the v1
tag and future releases therev1
instead. We will support master in a warned but deprecated state for ~1 month.node_modules
from the master branch. We will stay in this state for ~1 month.During steps 2 and 3, we need to be extra careful to not check the warning/error into the releases branch.
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?
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)
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 your issue is relevant to this repository, please delete this text and continue to create this issue. Thank you in advance.
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:
image: 'Dockerfile'
it's slow because the image is built from scratch every time the workflow runs.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.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.
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
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.
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
There does not seem to be any documentation referring to pythonLocation
.
^ 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!
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?
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).
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:
The error looks like:
test_first (tests.test_me.MyTest) ... ok
##[error]Process completed with exit code 1.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.