This is a pex-specific ticket for the feature proposal in: pantsbuild/pants#8031
To sum up, the current pex resolver error thrown at runtime does not provide users with enough information as to what phase of the pex execution process creates a given runtime failure a la:
Failed to execute PEX file, missing macosx_10_13_x86_64-cp-36-cp36m compatible dependencies for:
cffi
cryptography
pyyaml
The key points for improvement are summarized in the linked ticket:
There seem to be a few bits that are critical: If PEX is in --build mode (it is by default) and it builds any platform specific wheels, it needs to note this and write down relevant constraints in its metadata noting the resulting pex for the same root platform can only run under said constraint. If PEX resolves a platform-specific wheel (as opposed to building it as in 1 above), it must use the resolved wheel platform info to update similar constraints to above.
The proposal here is to ensure that we provide error messaging and appropriate context based on what step of the bootstrapping process introduced the runtime interpreter/dependency incompatibility.
This is a pex-specific ticket for the feature proposal in: pantsbuild/pants#8031
To sum up, the current pex resolver error thrown at runtime does not provide users with enough information as to what phase of the pex execution process creates a given runtime failure a la:
The key points for improvement are summarized in the linked ticket:
The proposal here is to ensure that we provide error messaging and appropriate context based on what step of the bootstrapping process introduced the runtime interpreter/dependency incompatibility.