Speed up "sending tarball" step for PythonFunction CDK Construct

[bestickley]

What is the problem you're trying to solve?.
When I use the PythonFunction CDK construct, I'm experiencing very slow image build times. See example below. The slow step is the "sending tarball" part which takes ~60 seconds (per function) on every deploy. I'm not 100% sure this is a finch issue, but it seems like it might be related based on #412.

> cdk deploy "**" --require-approval never

Bundling asset lh-stickb/data/InitDbCR/DbMigrationFunction/Code/Stage...

  infra/cdk.out/bundling-temp-cc678e010fa9f9810641f894e6f344652008fa8a4cfc0b9c95358adb9dd01ee7/index.mjs      193.8kb
  infra/cdk.out/bundling-temp-cc678e010fa9f9810641f894e6f344652008fa8a4cfc0b9c95358adb9dd01ee7/index.mjs.map  977.5kb

⚡ Done in 104ms
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 1.32kB 0.0s done
#1 DONE 0.0s

#2 [internal] load metadata for public.ecr.aws/sam/build-python3.12:latest
#2 ...

#3 [auth] aws:: sam/build-python3.12:pull token for public.ecr.aws
#3 DONE 0.0s

#2 [internal] load metadata for public.ecr.aws/sam/build-python3.12:latest
#2 DONE 2.6s

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

#5 [1/2] FROM public.ecr.aws/sam/build-python3.12:latest@sha256:21608d5510c34056470cd48875d77be1a859b1a0a0471de1e73f61f80e05ee25
#5 resolve public.ecr.aws/sam/build-python3.12:latest@sha256:21608d5510c34056470cd48875d77be1a859b1a0a0471de1e73f61f80e05ee25
#5 resolve public.ecr.aws/sam/build-python3.12:latest@sha256:21608d5510c34056470cd48875d77be1a859b1a0a0471de1e73f61f80e05ee25 0.1s done
#5 DONE 0.1s

#6 [2/2] RUN     python -m venv /usr/app/venv &&     mkdir /tmp/pip-cache &&     chmod -R 777 /tmp/pip-cache &&     pip install --upgrade pip &&     mkdir /tmp/poetry-cache &&     chmod -R 777 /tmp/poetry-cache &&     pip install pipenv==2022.4.8 poetry==1.5.1 &&     rm -rf /tmp/pip-cache/* /tmp/poetry-cache/*
#6 CACHED

#7 exporting to docker image format
#7 exporting layers 0.0s done
#7 exporting manifest sha256:0088dd21c818679b3f1b9943c238614107f9549051f6f008d745be8b34cf2df0 done
#7 exporting config sha256:296cf64f3d73791e304b9c5f9236fdcad178f4c79c1cc97a6c972b2e9ad3d541 done
#7 sending tarball
#7 sending tarball 57.7s done // NOTICE HERE
#7 DONE 57.7s
unpacking docker.io/library/cdk-494312d8bd232151bea24b90d65d84f4c30e86e2996d22c26490f0d7e8b1a6e9:latest (sha256:0088dd21c818679b3f1b9943c238614107f9549051f6f008d745be8b34cf2df0)...
Loaded image: docker.io/library/cdk-494312d8bd232151bea24b90d65d84f4c30e86e2996d22c26490f0d7e8b1a6e9:latest

Describe the feature you'd like
I'd like the whole image build step to be cached, but if that cannot be done then for the "sending tarball" step to be faster.

Additional context
Finch Version: finch version v1.1.2
finch.yml:

cpus: 3
memory: 4GiB
creds_helpers:
    - ecr-login
vmType: qemu
rosetta: false

[Shubhranshu153]

@bestickley We have merged a pr upstream for this that would avoid creating tarballs.
Once it is in stable release for nerdctl we would update finch to avoid creating tarballs

containerd/nerdctl#2834