https://pantsbuild.org/ logo
Join Slack
Powered by
If I have a python module in `myorg/myapp/mycompon...
# general
a
If I have a python module in 
myorg/myapp/mycomponent/handler.py
and a BUILD for a pex_binary in mycomponent with an entrypoint of 
handler.py:run
, the resulting module in the binary is 
___pex__.myorg.myapp.mycomponent.handler
. Is there some way to introspect that at build time and retrieve that value? For context, I'm interested in building a plugin for the serverless framework that uses pants to build a lambda zip, but I'll need to be able to set the handler on the function correctly.
e
The 
__pex__
bit, no. That's magic available in all (modern) PEX files. You need to know if you're using that magic or not in the given usage context. The rest though is stored in PEX metadata:
Copy code
unzip -qc my.pex PEX-INFO | jq .
You'll notice an entry point field.
If you have 
pex
installed, 
pex-tools my.pex info
🙌 1
If the PEX file is 
--venv
or 
--include-tools
then 
PEX_TOOLS=1 ./my.pex info
a
You mentioned in that GH issue that the entry_point wasn't necessary. Could you give a 20 second summary of why? Sorry for peppering with noob qs.
e
The entry point allows you to execute the PEX as a single file binary: 
./my.pex
- but you're not doing that. The server less framework is executing the entry point you need to separately tell it about.
a
Understood
I think it's still useful in the case where I have multiple lambda handlers in a directory and I want to package them individually, right?
e
Nope. All it's useful for is if you want to run the PEX file directly and have it do a thing by default. Without an entry point a PEX will run, but act like a hermetic self contained venv and drop you in a repl with the PEX contents on sys.path.
a
so, if I have two handler modules 
get_foo.py
and 
upate_foo.py
, how would I specify separate pex_binaries for those?
e
A PEX with no entry point is substitutable for 
python
with all it's contents on that Python's sys.path.
@average-breakfast-91545 do you want 2 binaries or 1 binary with both handlers?
You can do either.
a
Two binaries
e
Then use two 
pex_binary
targets if using Pants.
Are you using Pants or just Pex?
a
Pants
e
Yeah, so that's all. That's sort of obvious though so I suspect something else is going on.
a
So use script over entry_point?
so I suspect something else is going on
Could well be just that I'm clueless
e
So, again, you don't need either for AWS lambda since you need to repeat yourself anyhow and re-tell that entry point to AWS in its config.
IE this PEX is not for running like 
./my.pex
It's a fancy zip sys.path entry.
a
Okay, so I have two python modules in a directory, with different sets of dependencies. I'd like to package those into two pex files containing only those dependencies. How do I specify those binaries?
That's what I'm not understanding 🙂
e
Make two separate 
python_source
(singular) targets to own the modules. Refer to 1 of those targets in the corresponding 
pex_binary
target.
👍 1
Then you can leave 
script
/ 
entry_point
off each and still get exactly and only what you need in each.
a
Thank you - you've been very helpful
e
If you want to not do that, then use 
entry_point
The 
script
is for console scripts, which is a 3rd party thing. These only: https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html#the-console-scripts-entry-point
👍 1
Open in Slack
PreviousNext
Powered by