fix: python version and sdk resolutions

[walln]

Added support for all AWS supported python runtimes except for 3.8 since it gets deprecated in October, and aligned all template pyproject.toml files to ensure local dev is consistent.

Something is wrong with resource linking and its not just a python function issue, waiting on some changes for that potentially, so this is not ready to merge.

[cmanou]

@walln was about to open pr for the python runtimes aswell I took a slightly different approach of build args adfdc0c thoughts?

[walln]

that's much better and I would rather go that route. I originally attempted to use build args to configure the entry point for lambdaric but had tons of issues, so the simple solution totally escaped me!

[cmanou]

Yes and no, the public.ecr.aws/lambda/python:3.12 image doesn't have find so its breaking at that stage but otherwise it did handle the arg correctly

❯ pnpm sst deploy
SST 3.1.15  ready!

➜  App:        aws-python-container
   Stage:      chris

~  Deploy

{ PYTHON_VERSION: '3.12' }
#0 building with "quirky_lovelace" instance using docker-container driver

sst/ion#1 [internal] load build definition from Dockerfile
sst/ion#1 transferring dockerfile: 1.09kB done
sst/ion#1 DONE 0.0s

sst/ion#2 [internal] load metadata for public.ecr.aws/lambda/python:3.12
sst/ion#2 ...

sst/ion#3 [internal] load metadata for ghcr.io/astral-sh/uv:latest
sst/ion#3 DONE 0.7s

sst/ion#2 [internal] load metadata for public.ecr.aws/lambda/python:3.12
sst/ion#2 DONE 1.3s

sst/ion#4 [internal] load .dockerignore
sst/ion#4 transferring context: 2B done
sst/ion#4 DONE 0.0s

sst/ion#5 [internal] load build context
sst/ion#5 DONE 0.0s

sst/ion#6 [auth] sharing credentials for <>.dkr.ecr.us-east-1.amazonaws.com
sst/ion#6 DONE 0.0s

sst/ion#7 FROM ghcr.io/astral-sh/uv:latest@sha256:a090e59a2ac5841745b875002f2bdaa208a381b92d2a0d69f29b6294329c2c69
sst/ion#7 resolve ghcr.io/astral-sh/uv:latest@sha256:a090e59a2ac5841745b875002f2bdaa208a381b92d2a0d69f29b6294329c2c69 done
sst/ion#7 DONE 0.0s

sst/ion#8 [stage-0 1/5] FROM public.ecr.aws/lambda/python:3.12@sha256:0a3d34a8310dc339ea7afeb64725df5685da2e6f335dc9287cbc0cddc4a159f2
sst/ion#8 resolve public.ecr.aws/lambda/python:3.12@sha256:0a3d34a8310dc339ea7afeb64725df5685da2e6f335dc9287cbc0cddc4a159f2 done
sst/ion#8 DONE 0.0s

sst/ion#9 importing cache manifest from snip.dkr.ecr.us-east-1.amazonaws.com/sst-asset:cache
|  Created     MyPythonFunction sst:aws:Function → MyPythonFunctionCode aws:s3:BucketObjectv2 (3.1s)
sst/ion#9 ERROR: failed to configure registry cache importer: snip.dkr.ecr.us-east-1.amazonaws.com/sst-asset:cache: not found

sst/ion#10 [stage-0 2/5] COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv
sst/ion#10 CACHED

sst/ion#5 [internal] load build context
sst/ion#5 transferring context: 12.87kB 0.0s done
sst/ion#5 DONE 0.0s

sst/ion#11 [stage-0 3/5] RUN echo "LAMBDA_TASK_ROOT: /var/task"
sst/ion#11 0.057 LAMBDA_TASK_ROOT: /var/task
sst/ion#11 DONE 0.1s

sst/ion#12 [stage-0 4/5] COPY . /var/task
sst/ion#12 DONE 0.0s

sst/ion#13 [stage-0 5/5] RUN PYPROJECT_DIR=$(find /var/task -name "pyproject.toml" -exec dirname {} ;) &&     if [ -n "$PYPROJECT_DIR" ]; then       cd "$PYPROJECT_DIR" && uv export && pip install -t /var/task .;     else       echo "pyproject.toml not found";     fi
sst/ion#13 0.030 /bin/sh: line 1: find: command not found
sst/ion#13 ERROR: process "/bin/sh -c PYPROJECT_DIR=$(find ${LAMBDA_TASK_ROOT} -name \"pyproject.toml\" -exec dirname {} \\;) &&     if [ -n \"$PYPROJECT_DIR\" ]; then       cd \"$PYPROJECT_DIR\" && uv export && pip install -t ${LAMBDA_TASK_ROOT} .;     else       echo \"pyproject.toml not found\";     fi" did not complete successfully: exit code: 127

[cmanou]

Fix for the find issue in 3.12 base image here if you want d6aeb54 basically just swap find for some grep and sed

[walln]

thats such a strange variance between the base images. thanks for the fix should be good now! @cmanou

[cmanou]

Yeah it was one of changes from Amazon Linux 2 to 2023 where they did a bunch of pruning that confused people amazonlinux/amazon-linux-2023#355

[walln]

This ended up being a way more significant PR than planned, but to get around to not being able to inject links into the environment, I had to do a much more convoluted build pipeline. There are a few benefits of these changes; monorepo structures should work as now all relative children pyi/pyi files are included in the artifact (this might close sst/sst#4114). I am not sure if I understand their issue properly. This will not hit the 4kb env var limit, and all Python versions are now supported.

The SDK is also under the SST namespace. (I will need to change the URL in the example before merging this, but it needs to resolve to a remote git branch, and currently, only my fork has the changes to the SDK)

from sst import Resource

def handler(event, context):
    return {
        "statusCode": 200,
        "body": f"{Resource.MyLinkableValue.foo} from Python!",
    }

This is fully typesafe using a generated Python type stub. (tracking the stub file in git is optional)

[cmanou]

@walln this didn't fixed sst/sst#4114, I realized my understanding of the problem was wrong see the example and fix here #1141. Basically findAbove starts returning an absolute path if the pyproject is up a directory from the handler which breaks the paths for copies after.

[toughrogrammer]

hi @cmanou, @walln, it looks something is broken in below commit.
walln@c226e67#diff-ea83e80a8a278f701ea3333102457d15c16ace0944c7c7dfd408da21ae33fdb4

i'm using sst v3.1.49. i tried to use python 3.12 runtime with docker container mode but i found python 3.11 docker image was used.
and finally, i found reason was docker build args were not given.
it looks like orignally codes were existed, but it's disappeared at above commit.