Python lambdas unable to find layers, external dependencies

[ocr-lasagna]

When using any python lambda that's been deployed via CDK, using either

aws-cdk.aws-lambda-python-alpha==2.252.0a0
With the format

new python.PythonFunction(this, 'MyFunction', {
  entry: '/path/to/my/function', // required
  runtime: Runtime.PYTHON_3_8, // required
  index: 'my_index.py', // optional, defaults to 'index.py'
  handler: 'my_exported_func', // optional, defaults to 'handler'
});

For the functions
and

new python.PythonLayerVersion(this, 'MyLayer', {
  entry: '/path/to/my/layer', // point this to your library's directory
})

for the layers

Or with our previous manual implementation

function = aws_lambda.Function(
            self,
            '<SomeName>',
            function_name='<SomeName>',
            description='Some description',
            runtime=aws_lambda.Runtime.PYTHON_3_12,
            architecture=aws_lambda.Architecture.X86_64,
            memory_size=512,  # In MiB
            timeout=aws_cdk.Duration.seconds(30),
            environment={ },
            handler='index.lambda_handler',
            code=aws_lambda.Code.from_asset(str(pathlib.Path(__file__).parent)),
            layers=[<some layer>],
            role=<some role>,
        )

and layer:

layer = aws_lambda.LayerVersion(
            self,
            '<some name>',
            layer_version_name=<some name>,
            description='Some description',
            compatible_runtimes=[aws_lambda.Runtime.PYTHON_3_12],
            compatible_architectures=[aws_lambda.Architecture.X86_64],
            code=aws_lambda.Code.from_asset(
                str(pathlib.Path(__file__).parent),
                bundling={
                    'image': aws_lambda.Runtime(
                        self.context.lambda_configuration.lambda_bundle_runtime, aws_lambda.RuntimeFamily.PYTHON
                    ).bundling_image, 
                    'command': [
                        'bash',
                        '-c',
                        ' && '.join(
                            [
                                *context.lambda_configuration.extra_prebuild_commands,
                                # Baseline move things to /asset-output
                                'mkdir /asset-output/python',
                                'rsync -rLv /asset-input/ /asset-output/python',
                                # Install from requirements.txt
                                '(if [ ! -f /asset-output/python/requirements.txt ]; then touch /asset-output/python/requirements.txt; fi;)',
                                'python -m pip install -r /asset-output/python/requirements.txt -t /asset-output/python',
                                # Move lib,bin,etc out of python directory
                                '(if [ -d /asset-output/python/lib ]; then mv /asset-output/python/lib /asset-output; fi;)',
                                '(if [ -d /asset-output/python/bin ]; then mv /asset-output/python/bin /asset-output; fi;)',
                                '(if [ -d /asset-output/python/etc ]; then mv /asset-output/python/etc /asset-output; fi;)',
                            ]
                        ),
                    ],
                },
            ),
        )

Any time a lambda is invoked, we receive an error such as

{ "errorMessage": "Worker init failed: No module named 'pydantic'", "errorType": "RuntimeError" }
for any package that is included in the requirements.txt, as well as for any imports from layers (such as, Worker init failed: No module named 'layerName')

Is there full support for Python Lambdas and Layers in Ministack, or is there some problem with our setup? These lambdas all perform as expected when deployed to AWS so it's been a bit of a headscratcher as to why the layers and packages arent available when deployed to ministack, as the layers are showing up when awslocal lambda list-layers is called:

       {
            "LayerName": "LayerName",
            "LayerArn": "arn:aws:lambda:us-east-1:000000000000:layer:LayerName",
            "LatestMatchingVersion": {
                "LayerVersionArn": "arn:aws:lambda:us-east-1:000000000000:layer:LayerName:1",
                "Version": 1,
                "Description": "Description",
                "CreatedDate": "2026-06-16T20:43:54.240Z",
                "CompatibleRuntimes": [
                    "python3.12"
                ],
                "LicenseInfo": "",
                "CompatibleArchitectures": [
                    "x86_64"
                ]
            }
        }

Any information or guidance is very much appreciated, and once again thank you for all your hard work on Ministack!

[Nahuel990]

Thanks for the detailed report; this is a bug in MiniStack, not in your setup. Your CDK configuration is correct.

Root cause: when a layer was deployed through CloudFormation (which is what CDK uses under the hood), MiniStack's CloudFormation provisioner fetched the layer ZIP from S3 but never persisted the actual content. The bytes were used to calculate metadata such as code size and hashes, then discarded. The direct PublishLayerVersion API path stores the content correctly; only the CloudFormation path was affected.

That's why you saw the split behavior:

• lambda list-layers worked because it only reads layer metadata, which was stored correctly.
• Function invocation failed because, at startup, the runtime attempts to retrieve and extract the layer ZIP onto the function's filesystem. Since no layer content had been persisted, the layer was effectively empty and skipped. As a result, modules provided by the layer, including dependencies installed via pip install -t, were unavailable, leading to errors such as No module named 'pydantic'.

Fix: the CloudFormation layer provisioner now stores the layer ZIP content, making CloudFormation/CDK-deployed layers behave the same as layers published through the Lambda API. I've also added a regression test that deploys a layer and function through CloudFormation and verifies that packages from the layer can be imported successfully at invocation time. The fix will be included in the next release.

Thanks again for the clear reproduction steps and the kind words. Reports like this make MiniStack better.

[Nahuel990]

It should work from v1.3.65

[ocr-lasagna]

Hello, sorry for the delay in following up, just wanted to update really quickly with a follow on issue I'm seeing --

The fix from v1.3.65 fixed the issue we were seeing with the Layer code, however the resolved imports seem to be exclusively the ones from the layer's code itself, minus the dependencies from the requirements.txt file in said layers, leading to import failures such as

{
  "errorMessage": "Worker init failed: No module named 'pydantic_core._pydantic_core'",
  "errorType": "RuntimeError"
}

{
  "errorMessage": "Worker init failed: cannot import name '_imaging' from 'PIL' (/tmp/ministack-lambda-<lambda name>-lvrqi7bp/layer_1/python/PIL/__init__.py)",
  "errorType": "RuntimeError"
}

{
  "errorMessage": "Worker init failed: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /tmp/ministack-lambda-<lambda name>-kbqfs8gd/layer_0/python/pymupdf/libmupdf.so.27.2)",
  "errorType": "RuntimeError"
}

So effectively any imports from external packages included via the packaging methods above (either with the PythonLayerVersion or the manual Layer packaging) from requirements.txt fail on import, however the accompanying layer code does import correctly (assuming none of the packages in requirements.txt are being used)

That is, in our lambda code:

import json # works
import os # works

import boto3 # works, I believe this is just included in lambdas by default though
from sample_layer.example import sample_function # works
from sample_layer.example.some_file import some_other_sample # works
import pydantic # Does not work -- any external packages included with the above sample_layer's requirements.txt fail to import, (such as PIL, or numpy, or libmupdf, etc)

Thanks again to you and the team for all your hard work!