Add support for in-development Python versions

[jhenstridge]

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).

[L1ghtn1ng]

I second this, hope this gets fixed quickly

[asottile]

(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

[shadowmoose]

Came here to request this as well. Nightly builds would be awesome.

[L1ghtn1ng]

@madhurig Can we have an update on this please?

[madhurig]

We are still reviewing this and don't have a timeline unfortunately.

[L1ghtn1ng]

That is frustrating as would love to be able to get rid of Travis and would need support as well to allow failures of certain versions as well like Travis has. Then GH actions will then be a proper one stop shop for python then

…

________________________________ From: Madhuri Gummalla <[email protected]> Sent: Tuesday, February 18, 2020 2:29:50 PM To: actions/setup-python <[email protected]> Cc: J.Townsend <[email protected]>; Comment <[email protected]> Subject: Re: [actions/setup-python] Add support for in-development Python versions (#20) We are still reviewing this and don't have a timeline unfortunately. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#20?email_source=notifications&email_token=AA3V2QRTL3RKNKJBTH3RZFDRDPWF5A5CNFSM4IUEBUL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCFP7Q#issuecomment-587487230>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V2QXFLNSRTQZ4UOM75X3RDPWF5ANCNFSM4IUEBULQ>.

[cjolowicz]

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

[cclauss]

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.

[hugovk]

@cclauss Perhaps put all the commands in a bash script and run it like nightly.sh || true?

https://serverfault.com/a/228287

[isidentical]

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.

[henryiii]

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?)

[asottile]

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

[adamchainz]

@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).

[asottile]

I've also added 3.10-dev support to the deadsnakes action

[jadchaar]

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.

[konradpabjan]

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

[agronholm]

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.

[gaborbernat]

@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.

[agronholm]

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?

[hugovk]

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

[agronholm]

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.

[cclauss]

Available choices are at https://github.com/actions/python-versions/releases

[hugovk]

@agronholm I just tested with '3.9.0-alpha - 3.9' and it installed 3.9.6, sounds like what you're after:

• hugovk/test@71902c5
• https://github.com/hugovk/test/runs/3292477898?check_suite_focus=true

[toonarmycaptain]

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

[cclauss]

@hugovk What happens with '3.10.0-alpha - 3.10'?

[gaborbernat]

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.

[hugovk]

@hugovk What happens with '3.10.0-alpha - 3.10'?

3.10.0-rc.1 👍

• hugovk/test@c8fa958
• https://github.com/hugovk/test/runs/3293472699?check_suite_focus=true

[agronholm]

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?

[toonarmycaptain]

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.

[zooba]

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.

[gaborbernat]

For me -dev implies a build from the version control main branch, so I'd recommend something like 3-canary instead of 3-dev.

[agronholm]

Whatever you decide, it should be documented, as -dev is currently not.

[EwoutH]

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:.

• Allow to specify only release level (alpha, beta, rc) instead of full version

[abe-101]

Is it possible to point to the latest stable version? As in whatever the current version is

[cclauss]

- uses: actions/setup-python@v3 # without a with block or a python-version usually provides the latest stable Python.