feat: add nox runner

[henryiii]

Closes #646. First pass at providing a Nox interface to common tasks.

[joerick]

Looks really nice! So nox ends up being a task-runner, too, kind of like a Makefile.

Buuut, hmm, just thinking about dependencies - the downside of using nox like this is that we rely on GHA having the right versions of Python available. This might not be the case in a beta situation, where we want to generate a 3.10 constraints file but GHA hasn't added it yet? The nice thing about relying on the manylinux image was that the manylinux image was already a dependency, so we weren't adding any more Python version constraints.

Could we get into a situation where we want to add a beta version of Python but we can't because GHA doesn't support it yet?

[henryiii]

GHA gets new versions of Python about 24 hours after they get released, including Alpha versions (at least, they become installable via setup-python@v2, which is all you need - the nox action is simply a front for running setup-python multiple times). But there's really no special requirement here, all nox needs is the versions of Python somewhere - you could even use the manylinux docker images as long as you installed nox before running nox (and possibly setup the paths a bit, since it might not be able to find the manylinux locations natively?).

Actually, here's a quick proof of concept:

$ docker run --rm -v $PWD:/src -it quay.io/pypa/manylinux_2_24_x86_64
# cd /src
# /opt/_internal/tools/bin/pip install nox
# ln -s /opt/python/cp36-cp36m/bin/python3.6 ../usr/local/bin/.
# ln -s /opt/python/cp37-cp37m/bin/python3.7 ../usr/local/bin/.
# ln -s /opt/python/cp38-cp38/bin/python3.8 ../usr/local/bin/.
# ln -s /opt/python/cp39-cp39/bin/python3.9 ../usr/local/bin/.
# /opt/_internal/tools/bin/nox -s update_constraints

@mayeut why are the altinstall names not available in manylinux /usr/local/bin? Was it a historical reason when python 2.7 had two different versions, perhaps, or something else?

[mayeut]

@mayeut why are the altinstall names not available in manylinux /usr/local/bin? Was it a historical reason when python 2.7 had two different versions, perhaps, or something else?

I don't have the full history. Maybe the reason you mention is one factor, maybe no one had the need or asked for it. Now that python 2 is gone I'd gladly accept a PR adding those symlinks (& maybe pip3.? ones also). I'd even go for a python & python3 symlink to "the mainstream" python version (i.e. probably 3.7 today).
I doubt we'll ever get in a state where multiple "default" ABI coexists again & even if this becomes the case, we can document the symlinked ABI.

[henryiii]

Okay, great, noted!

I'd even go for a python & python3 symlink to "the mainstream" python version (i.e. probably 3.7 today).

I think I'd want to avoid this, as it could be easy to accentually build with the "mainstream" python when you intended to build with each version of Python, say in a loop. But the X3.Y names should be quite safe in that regard. (I'd actually be slightly templated to provide a pip symlink to the tools pip, with the intention that using it is a good way to install/upgrade "applications", but might also be too dangerous for the reason above?).

[mayeut]

@henryiii

I'd even go for a python & python3 symlink to "the mainstream" python version (i.e. probably 3.7 today).

I think I'd want to avoid this, as it could be easy to accentually build with the "mainstream" python when you intended to build with each version of Python, say in a loop. But the X3.Y names should be quite safe in that regard.

Well, given we can't remove the system python which is a dependency of other needed packages, it's already a mess:

Matt$ docker run -it --rm quay.io/pypa/manylinux1_x86_64:2021-05-06-1b0c111 python -V
Python 2.4.3
Matt$ docker run -it --rm quay.io/pypa/manylinux1_x86_64:2021-05-06-1b0c111 python3 -V
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "python3": executable file not found in $PATH: unknown.
Matt$ docker run -it --rm quay.io/pypa/manylinux2010_x86_64:2021-05-05-e1501b7 python -V
Python 2.6.6
Matt$ docker run -it --rm quay.io/pypa/manylinux2010_x86_64:2021-05-05-e1501b7 python3 -V
/usr/local/bin/manylinux-entrypoint: line 8: exec: python3: not found
Matt$ docker run -it --rm quay.io/pypa/manylinux2014_x86_64:2021-05-05-e1501b7 python -V
Python 2.7.5
Matt$ docker run -it --rm quay.io/pypa/manylinux2014_x86_64:2021-05-05-e1501b7 python3 -V
/usr/local/bin/manylinux-entrypoint: line 8: exec: python3: not found
Matt$ docker run -it --rm quay.io/pypa/manylinux_2_24_x86_64:2021-05-05-e1501b7 python -V
/usr/local/bin/manylinux-entrypoint: line 8: exec: python: not found
Matt$ docker run -it --rm quay.io/pypa/manylinux_2_24_x86_64:2021-05-05-e1501b7 python3 -V
Python 3.5.3

One can argue that python3 is slightly more dangerous than just python these days.

(I'd actually be slightly templated to provide a pip symlink to the tools pip, with the intention that using it is a good way to install/upgrade "applications", but might also be too dangerous for the reason above?).

The applications/tools are in fact not directly accessible, there's just a symlink to auditwheel in /usr/local/bin if I'm not mistaken.

We can take this over to a manylinux issue if you want to revisit what's being done there.

[joerick]

But there's really no special requirement here, all nox needs is the versions of Python somewhere - you could even use the manylinux docker images as long as you installed nox before running nox (and possibly setup the paths a bit, since it might not be able to find the manylinux locations natively?).

That's good to know. Yeah, I'm encouraged by the simplicity of your proof-of-concept - that would be a nice escape hatch if we ever had issues with GHA's Pythons, or wanted to run this locally for some reason. Even better if nox happened to work natively in a manylinux image through those symlinks you mention!

[henryiii]

Assuming you also saw in the docs, there is a recommended docker image for nox too:

docker run --rm -it -v $PWD:/src thekevjames/nox nox -f src/noxfile.py -s update_constraints

That can be run in GHA too, like:

test:
    runs-on: ubuntu-latest
    container: thekevjames/nox:2020.12.31
    steps:
        ...
        - run: nox

(Readme is a little hard to find from the docker readme, and uses outdated syntax for the example)

[mayeut]

I wonder how I didn't come across this one before. I probably added a global rule for this at some point...

[mayeut]

Even better if nox happened to work natively in a manylinux image through those symlinks you mention!

Just merged PR from @henryiii to check this and it works well. I now wonder if it makes sense to add nox or pipx to the manylinux images ?

[joerick]

I don't know about nox (maybe too specific a tool?), but having pipx inside manylinux seems like a nice idea! Then we could do pipx run nox.

[henryiii]

pipx sort of removes the requirement to have any other tools due to pipx run nox==2020.12.31 or pipx run tox, pipx run build, pipx run auditwheel, pipx run twine, etc. Important/pinned tools like auditwheel or build would continue to be built in, but pipx would provide a good way to use unincluded tools or specific versions easily.

[henryiii]

FYI this works now

[joerick]

That's really nice. 👏

[henryiii]

I've moved nox -s serve into a option on docs, nox -s docs -- serve.

[joerick]

Looks good to me! Up to you if you'd rather merge this or #675 first!

[henryiii]

Happy to get this in as soon as possible, because I like using it. :)