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)
- Custom setuptools version HOT 12
- Cannot load Python modules if they are in a directory named "test" HOT 7
- Python 3.7/8/9/10 on Darwin runners fails: Library not loaded: /usr/local/opt/gettext/lib/libintl.8.dylib HOT 6
- Setups HOT 1
- My pro HOT 1
- Missing support for Python 3.8 on Ubuntu 24.04 runner HOT 2
- Caching doesn't seem to save that much time HOT 6
- Version not found when using new arm-based linux runners (ubuntu 22.04) HOT 4
- Add Python 3.12.4 (released 2 days ago) HOT 6
- [Feature Request] Add Python debug builds with `Py_DEBUG` flag HOT 1
- Python 3.12.4: Extract downloaded archive; gzip: stdin: not in gzip format HOT 22
- is python 3.12.4 download assets broken HOT 7
- Python 3.13 fails to install on windows: Offset to Central Directory cannot be held in an Int64. HOT 6
- Verify checksum of downloaded version archive HOT 1
- Support os-release standard HOT 5
- setup-python CI workflows have been broken for more than 2 months HOT 1
- Sporadically missing patch versions on python-versions for arm64 HOT 5
- `python-version-file` does not support multiple versions HOT 2
- Cannot parse version number from TOML 1.0.0 pyproject.toml file HOT 5
- Associate .py with python on Windows 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.