With this potential switch from Lambdex/`python_awslambda` to PEX/`pex_binary` , is there a way to replace the behaviour of

lambdex_handler.handler

? That is, a universal entrypoint that runs whatever is configured in a

BUILD

file. Previously, with

python_awslambda

, we set

handler="path/to/whatever.py:handler"

which both defines the 'root' of the packaging and also the handler function, and then our CDK construct for a pants lambda just needs to be told about the zip file and we're good to go (the construct can just set

handler: 'lambdex_handler.handler'

because that always works). With PEX, it seems like we'll have to set

entry_point="path/to/whatever.py:handler"

(or just the file) to define the packaging, and then duplicate that into the CDK construct by also specifying

path.to.whatever:handler

. This is annoying to write twice, and risks inconsistencies.

Interesting. I had always assumed that having a fixed handler at the CDK level was a nuisance, not a benefit. I think the plan (when someone gets around to it) is to modify the existing backend to produce pexes with a .zip extension and set the handler in the same way, so you can switch to the new implementation without having to change anything, and then let users opt out of the fixed handler. But it sounds like that might not even be desirable, in your case!

Yeah, I’m just feeling this out as I go (investigating switching to using PEXes directly), and I think you’re right that that wouldn’t be desirable for us: the handler function is intimately connected to the packaging for ~all lambdas, and specifying that twice info seems annoying. (The only case we might want to override is multiple lambdas that use different handlers within one file, but that’s pretty rare for us.)

It would be easy enough to keep the interface as is. Along with growing support for

__pex__

Pex also finally got support for closing over environments. Both were needed to free itself from API consumers to allow cleanly cutting over to Pex 3.x. The closing over environments thing would mean lambdex can change to shipping as just another distribution that was a main-delegator ~like uvicorn. So lambdex then just has a fixed lamdex_handler:handle but where that delegates to can be controlled from env vars. On the Pants side we'd just use Pex's ~new:

--inject-env INJECT_ENV
                        Environment variables to freeze in to the application environment. (default: [])

To freeze in your handler from the BUILD file target metadata as-is today.

Thanks, I think that sounds reasonable. I take from the discussion that this isn't currently supported. (Faster cold starts would be handy, e.g. ours got noticably slower when we switched to using Lambdex-driven lambdas)