https://pantsbuild.org/ logo
Join Slack
Powered by
An interesting observation. Having a `pex_binary` ...
# general
f
An interesting observation. Having a 
pex_binary
declaration only, and if the 
entry_point
file is not listed as 
sources
, the PEX file is still produced, but isn’t usable since the module is absent.
the BUILD file:
Copy code
pex_binary(
    name='pex-binary',
    description='Description',
    entry_point='main.py:main',
)
the workflow:
Copy code
$ ls projectA 
BUILD   main.py

$ ./pants filedeps projectA::                                             
projectA/BUILD

$ ./pants package projectA:: 
$ python3 dist/projectA/pex-binary.pex
...
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'main'
Is this intentional? I.e. if entry point specifies a file that is not under sources, it still happily packages the PEX binary, however, we know already at the packaging step that the PEX won’t be usable. Do you think we should evaluate the entry point eagerly to confirm the module specified is under sources?
h
Yes that is intentional, if you want to set the entry point to third-party requireemnts or the standard library
✅ 1
related is the 
script
field, which lets you do things like 
script='black'
to build 
black.pex
✅ 1
e
IIUC this is intentional, but still bewildering for an end user. All the metadata that should be needed is present. It turns out Pants needs a 
python_source
target for internal book-keeping reasons. Pex could help here and error for all invalid entry points instead of just invalid console script entry points (it actively tries to find those in the resolved set so it can translate them to entry points and fails fast if not found). So Pex could be more uniform and blow up if an entry-point is not present in 3rdparty deps or 
--sources
. That blow-up would be a lot friendlier than shipping a silent broken PEX.
4 Views
Open in Slack
PreviousNext
Powered by