SAM debug fails with layer BuildMethod:makefile

[pbarvinko]

Describe the bug

I have a sam application, which has a python lambda function. This lambda function depends on a lambda layer. This layer has a BuildMethod: makefile in its template.yaml definition. The sam applications builds fine with sam build and can be deployed to AWS and works correctly after being deployed. However, when I attempt to debug this lambda function locally using vscode, the sam build step fails with "Make Failed: make: *** No rule to make target" error. During the investigation I executed the statements, which debugger executes manually with --debug switch and compared their output to the regular sam build output.

The correctly executed make statement looks like this: executing Make: ['make', '--makefile', '/home/test/work/projects/testproject/lambda/shareddepslayer/Makefile', 'build-shareddepslayer']

While the make statement, executed during the debug build is this: executing Make: ['make', '--makefile', '/tmp/aws-toolkit-vscode/vsctkQvLSJf/debug-requirements.txt', 'build-shareddepslayer']

This suggests that vscode SAM debug build process wrongfully takes a manifest file as a parameter for make instead of Makefile.

To Reproduce

1. Create a SAM application with a python lambda function, which depends on the layer
2. Layer shall use BuildMethod: makefile
3. Add Debug Configuration for this function to launch.json
4. Start debugging

Expected behavior

SAM build shall succeed and debugging session shall start properly

Desktop (please complete the following information):

OS: Linux x64 4.19.128-microsoft-standard Visual Studio Code Extension Host Version: 1.52.1 AWS Toolkit Version: 1.18.0

[justinmk3]

Thanks for the report! Currently the Toolkit doesn't support layers in SAM templates.

We might need to set up path mapping for the layer: https://github.com/aws/aws-toolkit-jetbrains/issues/3261

[pbarvinko]

Maybe, it is only loosely related, but I want to write here about the workaround that I have eventually found in the hope that it can help others to save hours of frustration not to be able to debug locally a lambda in python, which uses layer as a dependency.

So, I first tried BuildMethod: python3.8 and it did not work - under debugger my lambda has failed with "import jose" - could not find module jose - which was in the requirements.txt of the layer itself. To fix it, I tried to use the BuildMethod: Makefile, which did not work either as described in this issue.

So, I went back to using BuildMethod: python3.8 and after investigation I have found out that the issue is caused by the fact that toolkit ignores requirements.txt for a layer and uses its own debug-requirements.txt instead (@justinmk3 - I think that this is another toolkit issue). Inside debug-requirements.txt there is only one module - debugpy>=1.0,<2.

So, here is my workaround:

• I created a new file, called vscode-debug-requirements.txt. This file has all modules from requirements.txt of my layer plus debugpy. In my specific case it looked like this:

  debugpy>=1.0,<2
  python-jose[cryptography]

• I added sam section to the lambda function configuration in launch.json:

            "sam": {
                "buildArguments": ["--manifest", "/home/test/work/projects/testproject/lambda/vscode-debug-requirements.txt"]
            }

note: you have to use a full absolute path, unfortunately, as buildArguments do not understand the vscode variables (@justinmk3 - maybe another toolkit issue:) )

And, voila, I was able to debug my lambda locally with all its dependencies! I do see that --manifest is provided two times as an argument to sam build - first with debug-requirements.txt and then - with vscode-debug-requirements.txt. The last apparently wins, which is good enough for me.

Hope, this information will be helpful to other folks.

[justinmk3]

you have to use a full absolute path, unfortunately, as buildArguments do not understand the vscode variables

@pbarvinko this should be fixed since 1.23 , can you confirm?

the issue is caused by the fact that toolkit ignores requirements.txt for a layer and uses its own debug-requirements.txt instead ... Inside debug-requirements.txt there is only one module - debugpy>=1.0,<2.

Thanks for identifying this. Layers support is a known issue and it helps to enumerate specific problems.