Comments (37)
We have added support for pre-release Python versions!
If you use actions/setup-python@v2
, you can use the latest 3.9.0-beta.4
. All available versions can be seen here: https://github.com/actions/python-versions/blob/main/versions-manifest.json
The readme
has also been updated with some information: https://github.com/actions/setup-python#usage
We currently only have the 3.9.0-beta.4
version available as it is the most recent: https://www.python.org/download/pre-releases/
In the future, once new pre-release versions are available, they will added to the available versions in actions/python-versions
from setup-python.
I decided to package this up into a github action which should make it easier to use -- you can check that out here: deadsnakes/[email protected]
if anyone knows how to call the default setup-python action as a fallback, that would be great (then it could seamlessly work without having to do the wacky if:
checks
from setup-python.
Here is an approach using deadsnakes, based on @asottile's comment above:
jobs:
tests:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ['3.6', '3.7', '3.8', '3.9']
name: Python ${{ matrix.python-version }}
steps:
- uses: actions/checkout@v2
- name: Install Python 3.9
if: matrix.python-version == '3.9'
run: |
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install -y --no-install-recommends python3.9-dev python3.9-distutils python3.9-venv
python3.9 -m pip install --upgrade pip setuptools
python3.9 -m venv $HOME/venv-python3.9
echo "::set-env name=VIRTUAL_ENV::$HOME/venv-python3.9"
echo "::add-path::$HOME/venv-python3.9/bin"
- uses: actions/setup-python@v1
if: matrix.python-version != '3.9'
with:
python-version: ${{ matrix.python-version }}
architecture: x64
from setup-python.
I've also added 3.10-dev support to the deadsnakes action
from setup-python.
Great, and 3.9-dev
seems to work too and currently picks up 3.9.0-beta.4
!
- python-pillow/Pillow#4799
- https://github.com/python-pillow/Pillow/pull/4799/checks?check_run_id=882879245#step:3:12
from setup-python.
Any idea when this will come to setup-python
? Python 3.9 has reached the beta stage and many libraries are now looking to test against it.
from setup-python.
I second this, hope this gets fixed quickly
from setup-python.
@asottile thanks for that. I've updated my projects to all test on Python 3.9 using the deadsnakes action, works like a (snake) charm(er).
from setup-python.
Came here to request this as well. Nightly builds would be awesome.
from setup-python.
from setup-python.
@cclauss Perhaps put all the commands in a bash script and run it like nightly.sh || true
?
https://serverfault.com/a/228287
from setup-python.
Version 2 now allows downloading custom versions, so it would be nice to add the 3.9 beta's to the list (maybe with the caveat that they may be removed after the full release?)
from setup-python.
This is great, but the -dev
suffix is not documented even though it appears to work. What I would like is for 3.X-dev
to install any latest available release of 3.X
, and 3.x
to install the latest stable version if it exists, or the latest prerelease version if no stable release exists. This way I could avoid having to update my GA workflows when new Python versions are released.
from setup-python.
I think there's a misunderstanding here. Right now the problem is Python 3.10. The specifier 3.10
doesn't work – I have to use 3.10-dev
instead and when 3.10 is released, I have to change it to 3.10
. Why couldn't I just use 3.10
so it gives me the latest beta/rc until a stable release, and from then on only stable releases?
from setup-python.
@hugovk What happens with
'3.10.0-alpha - 3.10'
?
3.10.0-rc.1
👍
from setup-python.
Whatever you decide, it should be documented, as -dev
is currently not.
from setup-python.
- uses: actions/setup-python@v3
# without a with
block or a python-version
usually provides the latest stable Python.
from setup-python.
(untested, just a suggestion) presumably you can use the same approach we're using on azure pipelines: install via deadsnakes
here's some sample code:
# for "released" versions (for example 3.8.0b4) use `ppa:deadsnakes` instead of the nightly
sudo add-apt-repository ppa:deadsnakes/nightly
sudo apt-get update
sudo apt-get install -y --no-install-recommends python3.8-dev python3.8-distutils
from setup-python.
@madhurig Can we have an update on this please?
from setup-python.
We are still reviewing this and don't have a timeline unfortunately.
from setup-python.
Travis CI has allow_failures
but GitHub Actions do not seem to have an equivalent. How would I get failing tests on any other version of Python to fail the entire build but run tests on nightly
in an allow_failures mode? We do not want contributors to close their PRs because of a bug that only appears on the Python nightly build. It is interesting to know that nightly fails but it is not a show stopper because nightly is not yet a shipping product.
from setup-python.
This issue is here for a long time, it would be very nice of this to resolved so we dont have to repeat the workaround in every new repo.
from setup-python.
@konradpabjan Awesome! What's the best way we can help get new prereleases into this? PR with URLs/versions? Just a ping?
from setup-python.
@agronholm that's a dangerous proposal, wouldn't it mean that when 3.x bumps you suddenly stop testing for 3.x-1? Feels like not a good place to be.
from setup-python.
Something like this?
Download and set up the latest available version of Python (includes both pre-release and stable versions):
steps:
- uses: actions/checkout@v2
- uses: actions/setup-python@v2
with:
python-version: '3.9.0-alpha - 3.9.0' # SemVer's version range syntax
- run: python my_script.py
https://github.com/actions/setup-python#usage
from setup-python.
Could that be modified to allow any patch release after 3.9.0?
EDIT: I realize one could do 3.9.0-a0 - 3.9.99
or something, but 3.9.0-a0 - 3.9.x
would look cleaner, and I think 3.9
should be an alias for that.
from setup-python.
Available choices are at https://github.com/actions/python-versions/releases
from setup-python.
@agronholm I just tested with '3.9.0-alpha - 3.9'
and it installed 3.9.6, sounds like what you're after:
from setup-python.
FWIW I'd like to be able to specify 3.7, 3.8, 3.9 and 3.10-dev (3.X-dev would be fine, and I'd change to 3.7, 3.8, 3.9, 3.10 and 3.X-dev after 3.10 is released, with any delay ).
If 3.X-dev changes to 3.11-dev by December, and I have to manually decide to test/support 3.10 when it is released, that seems ok to me?
I don't know if there's a 3.x for i in [whereever you get a list of major or minor releases from] but that would be a nice feature too, but opting in to major releases seems fine IMO.
3.X getting you the latest minor release seems a good convention - so 3.7 would get you 3.7.11, 3.9 would get you 3.9.6 etc
from setup-python.
@hugovk What happens with '3.10.0-alpha - 3.10'
?
from setup-python.
I don't think you want 3.11-dev because that would imply you follow the dev branch. This is not the case, you want to follow early releases, so IMHO 3.11.x is a more accurate representation.
from setup-python.
Is there any case where specifying a Python version without a stable release, without -dev
or other suffixes, should not give you the latest development version?
from setup-python.
I don't think you want 3.11-dev because that would imply you follow the dev branch. This is not the case, you want to follow early releases, so IMHO 3.11.x is a more accurate representation.
That is the case and is exactly what I'd like.
If I have to follow early releases and -dev separately to keep testing the changes between alpha/beta/rc versions, then that would work too, I'd like as soon as 3.10 is released proper, for my 3.whatever-dev to switchover to the 3.11 development branch. I used to switch over manually when the project I was working on was using Travis.
from setup-python.
I'd expect specifying 3-dev
to always get the latest build regardless of minor version number (in case it's not clear, the version number is input into a comparison, not a table lookup). That's going to be 3.10 stable for a while, as I wouldn't expect GHA to pick up 3.11 until the first alpha or beta. But then it should automatically switch over to the next version.
from setup-python.
For me -dev
implies a build from the version control main branch, so I'd recommend something like 3-canary
instead of 3-dev
.
from setup-python.
I just tested adding 3.11-dev
to my build matrix, and it installed 3.11.0-alpha.1
successfully.
I agree that it needs to be documented however. I would also like to remind you of my proposal in #210, to add adding alpha
, beta
and release-candidate
as possible values for python-version:
.
from setup-python.
Is it possible to point to the latest stable version? As in whatever the current version is
from setup-python.
Related Issues (20)
- Slow download HOT 4
- Caching conflicts when using `extra` dependencies HOT 2
- Unable to build requirement with pip HOT 4
- bad setuptools installation in actions/setup-python@v5 HOT 3
- my_script.py HOT 2
- Recommendations for caching poetry dependencies causes the wrong python version to be used for poetry install HOT 10
- Allow passing installer args to the Windows MSI HOT 1
- Importing psycopg2 (installed via pip) reports: ImportError: /opt/hostedtoolcache/.../3.13.0-alpha.6/.../psycopg2/_psycopg.cpython-313-x86_64-linux-gnu.so: undefined symbol: _PyInterpreterState_Get HOT 1
- macos-14-arm64 with provisionner 2.0.361.1+33a726b54233caea13315dba3887b0e7c5a1d482 can no longer load Python extension HOT 6
- Python 3.8 and 3.9 not found on macOS HOT 11
- Python Path is always first HOT 1
- no such option: --root-user-action HOT 23
- Failing with current ubuntu:latest container HOT 7
- x64 python fails on arm64 images HOT 5
- python3.7-arm64 is not available HOT 11
- Intermittent failures during Post Setup Python step for MacOS HOT 3
- Unable to locate 'pip' when using cache HOT 4
- python-3.7.17-darwin-x64 has broken readline module due missing libncurses HOT 1
- `setup-python` failing for 3.8 on `macos-latest` HOT 5
- Fails on Rocky Linux distro, missing `lsb_release` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from setup-python.