Add Python 3.14 built-in complete platforms for AWS Lambda

[jbsilva]

Problem

python_aws_lambda_function and python_aws_lambda_layer did not support
runtime="python3.14", even though AWS Lambda has supported the Python 3.14
runtime since November 2025.
Users were forced to manually generate and vendor a complete_platforms JSON
file as a workaround.

Solution

Add built-in complete platform configurations for Python 3.14 on both
x86_64 and arm64 (Graviton2), so users can simply write:

python_aws_lambda_function(
    name="my_lambda",
    handler="module:handler",
    runtime="python3.14",
)

Changes

• Add complete_platform_3.14-x86_64.json and complete_platform_3.14-arm64.json,
  generated from the official public.ecr.aws/lambda/python:3.14 Docker image
  using pex3 interpreter inspect --markers --tags --indent=2.
• Add PYTHON_314 to PythonAwsLambdaFunctionRuntimes and its
  RUNTIME_TAG_MAPPING entries for both architectures.
• Update test_to_interpreter_version to cover Python 3.13 (previously
  missing from tests) and 3.14.
• Add changelog entry.

Relates to #18195, #21656.

[sureshjoshi]

Thanks for the PR.

Two questions, per an upcoming LLM policy disclosure - were any LLMs or LLM-adjacent tools used to generate this PR?

Another one, how were the complete-platforms generated in this release? I see the note about the Docker image in the description - so was the pex output piped to a file?

[jbsilva]

Hi, @sureshjoshi.

Thanks for reviewing my PR!

I did it myself =).
I saw the previous changes that added support for Python 3.12 and 3.13 and replicated what was done for Python 3.14.
The changelog message, for example, was a copy from 3.12.

I generated the JSON files by running pex inside of real Lambda runtimes (x86 and arm64):

subprocess.run(
  "PYTHONPATH=/tmp/pex /tmp/pex/bin/pex3 interpreter inspect --markers --tags --indent=2",
  shell=True, capture_output=True, text=True
)

I also generated the files with the official Docker images and confirmed that the "compatible_tags" were identical. The command was:

docker run --platform linux/arm64 --rm \
  --entrypoint bash \
  public.ecr.aws/lambda/python:3.14 \
  -c "pip install pex -q && pex3 interpreter inspect --markers --tags --indent=2" \
  > complete_platform_3.14-arm64.json‎

[sureshjoshi]

Would you mind printing out what you get when you run (the x86_64 and arm versions straight from docker)

docker run --platform linux/arm64 --rm \
  --entrypoint bash \
  public.ecr.aws/lambda/python:3.14 \
  -c "pip install pex -q && pex3 interpreter inspect --markers --tags --indent=2"

Because I get something different, so I’m a little confused

[jbsilva]

Was the difference only in "marker_environment" (end of file)? If yes, that's fine.

I ran in 3 environments (real AWS, official Docker on WSL, official Docker on macOS) with the same results for "compatible_tags".

E.g. in a Mac:

❯ diff src/python/pants/backend/awslambda/python/complete_platform_3.14-arm64.json ~/complete_platform_3.14-arm64-macos.json
644c644
<     "implementation_version": "3.14.0",
---
>     "implementation_version": "3.14.3",
648c648
<     "platform_release": "5.10.247-277.989.amzn2.aarch64",
---
>     "platform_release": "6.8.0-50-generic",
650,651c650,651
<     "platform_version": "#1 SMP Sun Jan 4 17:20:01 UTC 2026",
<     "python_full_version": "3.14.0",
---
>     "platform_version": "#51-Ubuntu SMP PREEMPT_DYNAMIC Sat Nov  9 18:03:35 UTC 2024",
>     "python_full_version": "3.14.3",

Those last lines are only metadata about where the command was executed.
I preferred to commit the ones I got from running in real AWS Lambdas.

[jsirois]

I preferred to commit the ones I got from running in real AWS Lambdas.

@jbsilva more than prefer, these are the only correct ones to use. You went the extra mile there and that was correct to do. The issue you'd run into is with the "python_full_version": "3.14.3" tag (in practice there is 0 reliance in the ecosystem on the "platform_release": "6.8.0-50-generic" or "platform_version": "#51-Ubuntu SMP PREEMPT_DYNAMIC Sat Nov 9 18:03:35 UTC 2024" tags - these tags never should have been added to the spec, definitely not platform_version anyhow). There are real cases of distributions using python_full_version in marker expressions to say they are not compatible with early releases of a Python minor version series; i.e. there are markers like python_full_version >= "3.8.1" out in the wild. If there were such a marker for 3.14, say widget==2.0; python_full_version >= "3.14.1", then using the Docker image 3.14.3 would be a lie with an impact, since the AWS Lambda resolve would include widget==2.0 when it should not.

[sureshjoshi]

Thanks for the confirmation @jbsilva - was just checking why my spot check had a discrepancy. You confirmed it's what I thought it was coming from.