Set up GHA to test on Python 3.9-beta and 3.8-dev

[webknjaz]

GHA has recently started shipping Python betas so I thought I'd add it.
3.9.0-beta.4 - 3.9.0 is a semver range syntax that will get 3.9-beta set up in the worker.

I kept 3.9-dev and added 3.8-dev — these are still coming from deadsnakes PPA.

I've changed ubuntu-latest to concrete ubuntu-18.04 so that it's deterministic (at some point it'll be ubuntu-20.04 and that may come as a surprise).

I think it's possible to install the beta on macOS too but didn't know if that'd be wanted so I left it out.

[webknjaz]

Interesting... It looks like tox gets stuck on py39-beta

[jaraco]

3.9.0-beta.4 - 3.9.0 is a semver range syntax that will get 3.9-beta set up in the worker.

I don't know how to read this syntax, but I'd expect this syntax to include 3.9.0 final, which is inconsistent with the "pre-releases" indicator. How can we have confidence as to what this version specifies?

[webknjaz]

I don't know how to read this syntax,

Yeah, it's poorly documented @ https://github.com/actions/setup-python#usage:

Download and set up the latest available version of Python (includes both pre-release and stable versions):

    python-version: '3.9.0-alpha - 3.9.0' # SemVer's version range syntax

Ref: https://twitter.com/zooba/status/1284187985630593027

I also considered trying to enable beta from deadsnakes but it seems like @asottile only keeps one last beta, like 3.9.0~b4. So we cannot set 3.9-beta that would be auto-updated to the next beta and hardcoding will probably explode if b4 gets removed and replaced by b5...

[asottile]

I don't know how to read this syntax,

Yeah, it's poorly documented @ https://github.com/actions/setup-python#usage:

Download and set up the latest available version of Python (includes both pre-release and stable versions):

    python-version: '3.9.0-alpha - 3.9.0' # SemVer's version range syntax

Ref: https://twitter.com/zooba/status/1284187985630593027

I also considered trying to enable beta from deadsnakes but it seems like @asottile only keeps one last beta, like 3.9.0~b4. So we cannot set 3.9-beta that would be auto-updated to the next beta and hardcoding will probably explode if b4 gets removed and replaced by b5...

if you use 3.9 for the deadsnakes action it will always be the latest tagged version, 3.9-dev will be the latest nightly version

[webknjaz]

@asottile

if you use 3.9 for the deadsnakes action it will always be the latest tagged version, 3.9-dev will be the latest nightly version

But no such thing for betas, right?

[asottile]

@asottile

if you use 3.9 for the deadsnakes action it will always be the latest tagged version, 3.9-dev will be the latest nightly version

But no such thing for betas, right?

if the latest tagged release is 3.9b4 it will be the beta, if the latest tagged release is 3.9.1 it will be 3.9.1

[webknjaz]

Since it's still interesting why tox gets stuck under 3.9.0b4, I've added a live output option to tox for now.

[webknjaz]

So I have a suspicion that GH compiled it wrong: actions/setup-python#119.
It'd be interesting to see if this will explode under the deadsnakes beta (probably not, because it doesn't break with dev).

[TkTech]

If I had to guess, you're running into the same py3.9 issue I ran into as well when adding the py3.9 tests to https://github.com/TkTech/pysimdjson.

The fix is swapping the order of your steps. setup-python is including py3.9 in your working directory and your tests are trying to run the CPython tests as well. The checkout action cleans your working directory, so if you just swap the order presto it works.

See actions/setup-python#117 and actions/setup-python#106 for the upstream issue.

[webknjaz]

@TkTech that's an interesting suggestion. But if the GH-provided action has such regressions, I'd rather use deadsnakes instead of trying to fight their bugs...
Let's see what @jaraco thinks.

[webknjaz]

Alright, they've fixed the bug. @jaraco how would you like to proceed?

[jaraco]

Thanks for your patience and for pulling this together. I'm pretty confident my projects are going to migrate from Azure Pipelines to GHA soon, given that Azure Pipelines requires massive manual intervention to set each project up. Assuming I go that direction, your work here will be immensely valuable to the projects I maintain.

[webknjaz]

@jaraco in the light of that I want to share what I've learned recently. Apparently, you can now have an org-wide GHA workflows templates: https://docs.github.com/en/actions/configuring-and-managing-workflows/sharing-workflow-templates-within-your-organization.

[jaraco]

Indeed, I started looking into adopting github actions, but it seems that features like shared workflow templates and shared secrets only work for organizations. Do you think GitHub want individuals to create an organization to host the projects currently hosted in a personal account?

[webknjaz]

Dunno what GH wants but I personally use orgs as the means to group repos. But yea, I think they view this as something that orgs need more than individuals. Though, I'm not sure how useful it is to share secrets in public orgs — there's been some discussions in pytest and the conclusion was that creating an org-global PYPI_PASSWORD secret with a token is not a wise thing to do, security-wise, for example.