pex: /usr/bin/python3: can't find '__main__' module in 'blah.pex'
I have a pex file which i build via the following command:
pex -v -r requirements.txt -c gunicorn -D . -o blah.pex
which contructs a pex, installing requirement, and all files in project, setting entrypoint to gunicorn.
Build process works just fine. but when it comes time to run the pex, depending on where i run it ubuntu vm/ mac local/ ubuntu docker sometimes i get the following error:
/usr/bin/python3: can't find '__main__' module in 'blah.pex'
When I unzip the pex, i do see a main.py file in there, so im not sure what the problem is.
Has anyone experience this error? Ideas on what the problem is?
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 18 (11 by maintainers)
Okay, I recently had this problem as well and it turns out that python doesn’t know how to handle .pex files that are larger than 2gb in size and that gives you the incredibly useful “Can’t find main” error. So, check the size of your pex, if it is >2gb, it’s time to go on a dependency diet or try and find other ways to package/deploy your project
@dgkatz - finally looping back. was your issue related to the huge PEX issue @tentwelfths and @rom1504 encountered (>2GB PEX)? If so, I’d like to close this issue since @rom1504 confirms the
--layout packedPex option is a viable workaround.@tentwelfths hopefully
--layout packedgives you an escape hatch too when you simply can’t pare down dependencies.Sorry to see this so late - thanks for the bump with data @tentwelfths. Perhaps you could try the next Pex release or Pex master which now support a
--venvmode. If you build your PEX file using that flag, when run the PEX file will unpack itself into a virtual environment under~/.pex/venvsand re-execute from there. The upshot is the PEX runs just like any other Python application and size limits on the PEX zip file, etc are all sidestepped.@rom1504 Pex does already build in parallel using your number of cores by default (see
--helpfor--jobs). The build process looks like:pip download(this performs the resolve and downloads wheels and sdists)pip wheel(this builds any downloaded sdists into wheels)pip install(this installs each wheel in its own directory) The only remaining non-parallelized aspect of the PEX build for packed layout is zipping up all the individual wheel install chroots from step 3. That is done in serial: https://github.com/pantsbuild/pex/blob/7a6e9a46c7e4fc67c6d3f1a0fc19d5b204d5ee81/pex/pex_builder.py#L696-L719@tentwelfths I repro, although I get a different error message:
But the
--unzipremedy works. Here I simply use the runtimePEX_UNZIP(seepex --help-variables) equivalent instead of rebuilding the PEX file with--unzip. Slow 1st run when the initial unzip happens, fastish after that:Specifically,
--venvmode was added in #1153. Going to grab that PR link though reminded me the existing--unzipmode should provide the same remedy in this case. Perhaps you could also or alternatively try that?