Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

Sounds like you correctly set the handler to `lambdex_handler.handler` on the AWS side?

Try setting `zip_safe=False` on the `python_binary`

one more step I do after building from pex file from pants is run `lamdex build` on the generated pex, if I don't do that I get error saying `No such file or directory: xxx/PEX-INFO` while doing `lamdex test`.

`pants binary :hello-lambda`
I am using the example provided in the official repo. able to reproduce with that.

Then I didn't understand the part about running lambdex build yourself. What are you uploading to AWS, the result of `./pants binary`, or the result of running `lambdex build` yourself?

Also, can you provide the full stack trace to the error?

&gt; lambdex test --empty hello-bin.pex

Traceback (most recent call last):
  File "/usr/bin/lambdex", line 10, in &lt;module&gt;
    sys.exit(main())
  File "/usr/lib/python3.7/site-packages/lambdex/bin/lambdex.py", line 220, in main
    args.func(args)
  File "/usr/lib/python3.7/site-packages/lambdex/bin/lambdex.py", line 161, in test_lambdex
    with open(os.path.join(target, 'LAMBDEX-INFO'), 'rb') as fp:
FileNotFoundError: [Errno 2] No such file or directory: '/home/ray__/.lambdex/30b8a3d6928612d421290d9c72a4e6da1a5ae5b3451db7695b58eb3da6521a51/LAMBDEX-INFO'

&gt;What are you uploading to AWS
After running `./pants binary`, I get a pex file. I run `lambdex build` on the pex file and then zip the pex file and upload it.

OK, so try uploading the file you get from pants, without running `lambdex build` on it. There is no need for that, as pants already does it.

The `"Unable to import module 'lambdex_handler': No module named 'lambdex_handler'"` one

```
{
  "errorMessage": "Unable to import module 'lambdex_handler': No module named 'lambdex_handler'",
  "errorType": "Runtime.ImportModuleError"
}
```

Can you post the pex file you get from running `./pants binary`, and also your BUILD file

<@U051221NF> is this okay? uploaded to git
`<https://github.com/reaganrewop/lambda_pex>`

That's good, but I also need the pex from your `dist` dir

`hello-lambda.pex` is the result of applying lambdex to `hello-bin.pex`

Also, you mentioned that your command is `pants binary :hello-lambda`, does that mean your code is in the root of the repo? I can imagine that not working

If I run `./pants binary contrib/awslambda/python/src/python/pants/contrib/awslambda/python/examples:hello-lambda` in the pants repo, I get a valid lambda

So try uploading `hello-lambda.pex` and not `hello-bin.pex`, and if that doesn't work, also try moving the code under some subdir, like `src/python/hello`

<@U051221NF> it wasn't generating hello-lambda.pex if I use the goal as `binary` but works if I use `bundle`.

tested with `lambdex test` and it works but still when I upload it as zip to lambda service, it throws the same error which I mentioned before

<@U051221NF> I was able to make it work by deploying the pex without zipping

have you faced this issue before? zipping and uploading the pex is not working.

Ah, yes, I missed that detail. The thing you need to run on the cmd line is `pants bundle &lt;target&gt;`. There is an unfortunate historical distinction between `binary` and `bundle` that we may want to get rid of.

And you are supposed to upload the pex itself, you do not need to zip it. A pex is just a zip file with some header magic and a .pex extension.

What instructions were you following? Clearly I need to update them and clarify them.

I couldn't find any instruction, was just looking at pants code and lambdex code.

moreover, because of aws lambda size limitation I have to upload the pex file to s3 and get the link and share it to aws lambda. but if I do that It says `unzipped files should not exceed 269 mb`, eventhough the pex is just 100 mb. any reason for this?

is it trying to unzip it and telling me that the size is above 269 mb?

It sounds like you have this ~working? All you should need to do is `./pants bundle path/to/python_awslambda_target`, and then upload the resulting lambda pex to s3 the way you would any other lambda.

According to this: <https://docs.aws.amazon.com/lambda/latest/dg/limits.html> you are limited to a 50MB zipped/250MB unzipped pex size. An 100MB pex is pretty huge, are you using many large 3rdparty dependencies? Are you pulling in deps you may not actually need? The pex overhead is ~500K compressed, so that shouldn't be an issue. Your next step should probably be to figure out why your resulting bundle is so huge.

-.sh

Been running into this intermittent error. Running a command will result in a "bad file descriptor" error. Running the same command again works. This happens maybe every 4 runs or so?

I've seen this on multiple different commands, always intermittently, and it seems to be happening to others at my company.

i have a change to `plaintext_reporter.py` for this that i haven't pushed yet because nobody else was seeing it

i will push that and you can try to see if that fixes it, if you have the ability to run pants from source

i do not know why this started happening, though

The other intermittent failure we've been seeing is this one:

this one is slightly less frequent, but I'm seeing it multiple times a day.

that is actually another bug i am working on this week since a user reported it inside twitter

Both of these started some time after we upgraded to python3, and before we upgraded to `1.20.0.dev1` (so... May? ish? I can probably nail that down a bit.)

could i ask you to do a huge favor and copy/paste the exact text of your slack messages into separate issues on github? if you don't have the bandwidth right now i will follow up later today

<@U098KD4HJ>: are you by any chance editing your plugin code?

editing your plugin code triggers a pantsd restart

In this case I am iterating on some totally unrelated tests.

I did see the same error while working on a new rule, but it doesn't seem to be specific to that.

when this happened inside twitter the user was not editing a pants plugin, just checking since we're not sure of the cause of this second issue yet

i mean, it will happen anytime the daemon restarts. including the log from the daemon is the relevant bit.

but yea, if you are editing plugin code, restarts are expected... making them more graceful would be good though.

<@U098KD4HJ>: are you able to include the `.pants.d/pantsd/pantsd.log`?

that should explain a bit more about why the service went down

(on this one, i mean: <https://github.com/pantsbuild/pants/issues/8198>)

My logs are full of "bad file descriptor" and I'm having trouble finding something relevant for the other error. Will add it when I find it.

That same exception message (service shutting down) should have been rendered in the log... so yea, if you see another, the nearby log is the relevant bit