The gcr.io/cloud-devrel-kokoro-resources/python:latest needs to be updated with python 3.7/3.11 before merging. We should also add a line to configure nox to error on missing interpreters so that the build fails. See https://github.com/googleapis/python-language/blob/main/noxfile.py#L75

nox > Running session lint-3.7
nox > Session lint-3.7 skipped: Python interpreter 3.7 not found.
nox > Running session lint-3.11
nox > Session lint-3.11 skipped: Python interpreter 3.11 not found.
nox > Running session test-3.7
nox > Session test-3.7 skipped: Python interpreter 3.7 not found.
nox > Running session test-3.11
nox > Session test-3.11 skipped: Python interpreter 3.11 not found.

So now I am perplexed.
The python Docker image is based off of the python-base Docker image and should thus get all the interpreters that we are adding to python-base in this PR.
When the tests for this are run, I wonder if the kokoro CI presubmit is running using an older version of the python Docker image and thus will never see the Python interpreters until the python image gets rebuilt properly.

Do we have a chicken and the egg situation here?

Can we force each of the python related images to be built so that the daisy chain can function properly? OR am I just missing something cause computers are hard?

In the python base image, it looks like we only have python 2.7 and python 3.9
https://github.com/googleapis/testing-infra-docker/blob/main/python/cloud-devrel-kokoro-resources/python-base/Dockerfile#L97.

We'll need to update the python base Dockerfile to something like this to install all versions
https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/.kokoro/docker/Dockerfile#L120

We should also modify the Dockerfile to test all versions like we do here
https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/.kokoro/docker/Dockerfile#L166

In the python base image, it looks like we only have python 2.7 and python 3.9 https://github.com/googleapis/testing-infra-docker/blob/main/python/cloud-devrel-kokoro-resources/python-base/Dockerfile#L97.

This has been updated but is waiting on a PR merge.
https://github.com/googleapis/testing-infra-docker/pull/301/files/cf5264f6b4e5a1961b1a3311ce6004ccb7c83fb8#

We'll need to update the python base Dockerfile to something like this to install all versions https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/.kokoro/docker/Dockerfile#L120

See note above.

We should also modify the Dockerfile to test all versions like we do here https://github.com/GoogleCloudPlatform/python-docs-samples/blob/main/.kokoro/docker/Dockerfile#L166

Will do.

@chalmerlowe / @parthea We have a separate PR to update some dependencies for the java-specific requirements.txt (#1829). It's currently failing the kokoro build with this error:

Executing: docker run --rm --interactive --network=host --privileged --volume=/var/run/docker.sock:/var/run/docker.sock --workdir=/tmpfs/src --entrypoint=github/synthtool/.kokoro/build.sh --env-file=/tmpfs/tmp/tmph267ibdj/envfile --volume=/tmpfs:/tmpfs gcr.io/cloud-devrel-kokoro-resources/python
nox > Running session lint-3.6
nox > Creating virtual environment (virtualenv) using python3.6 in .nox/lint-3-6
nox > Command /usr/local/bin/python3 -m virtualenv /tmpfs/src/github/synthtool/.nox/lint-3-6 -p python3.6 failed with exit code 1:
RuntimeError: failed to find interpreter for Builtin discover of python_spec='python3.6'
nox > Session lint-3.6 failed.
nox > Running session lint-3.10
nox > Missing interpreters will error by default on CI systems.
nox > Session lint-3.10 skipped: Python interpreter 3.10 not found.
nox > Running session test-3.6
nox > Creating virtual environment (virtualenv) using python3.6 in .nox/test-3-6
nox > Command /usr/local/bin/python3 -m virtualenv /tmpfs/src/github/synthtool/.nox/test-3-6 -p python3.6 failed with exit code 1:

I'm wondering if this PR with the update to the python versions will fix this issue? Or is this totally unrelated? Thanks in advance for any guidance!

@alicejli / @parthea

This PR should fix the issue that you are referencing: googleapis/testing-infra-docker#301

It updates python-base docker image with a wide variety of interpreters.
python-base is the foundation of the python docker image, so those interpreters should carry into python.
That and this PR should ensure that the correct python interpreters are present and should eliminate the error above.

googleapis/testing-infra-docker#301 is waiting on review.
And should be implemented before this one (note, it will take a while for the docker image to update once that PR is pushed through ... could be up to an hour and 15 minutes).

Based on a very quick search, it looks like we might need to get into the docker image and install the following:

libffi-dev

https://stackoverflow.com/questions/27022373/python3-importerror-no-module-named-ctypes-when-using-value-from-module-mul

I am gonna do a bit more digging to see if there might be anything else that needs to go into the docker container. Once I feel confident, I will make the edits to the appropriate testing-infra-docker image(s).

Tried to update python-base with libffi-dev.
Once that goes through the process and is built, we can try this PR again to see if it passes tests.
SEE:
googleapis/testing-infra-docker#310

For some unknown reason, while the latest Python image is being used it is not the correct image.

The image tagged latest was the most recent image that was uploaded to the image repository, but it is not the most recently created image.

Got a question in the Google Chat to get some clarity on what might have caused this discrepancy/how to avoid it. Will need to retag the images and try to rerun the checks on this repo.