John Sirois

> If I'm hearing you right, it sounds like you're advocating for something a little different: the ordering of: I'm advocating for don't muck with essentially unrelated stuff in this...

> Would it be useful to put __main__.py at the literal very end, then? Yes, but `__pex__/__init__.py` also has the same role when the PEX is used as a sys.path...

Just noticed this: >> Ok. The docs are in a sorry state to be sure, but that can be remedied. > That wasn't my intention -- please don't assume antagonism....

Re the commit description, I'm still not a fan of the formula - you can say the exact same thing without the damn template. But that's just my grumpy dislike...

@cosmicexplorer although this PR is approved, another thing to weigh is #2298 which provides even greater speedups with 0 hacks by skipping zipping entirely with a bonus of skipping unzipping...

Can you explain a bit more? Do you have situations where building the PEX file with `--runtime-pex-root X` is not enough? If so, can you provide more details about your...

Aha, ok. So the PEX runtime tries `os.mkdir` on `/disk1` which nets an `OSError` (or `IOError`) due to a disk full condition and then falls back to `/disk2`. That makes...

OK, thanks for the background. The health checker approach is the right approach! You need a daemon or a cron job for that. Pex is neither, it's a one-shot job....

Maybe this makes things clearer. Pex can restart itself if needed since it knows what its constraints are. It cannot, however restart user code - that might be disastrous. Who...

Ok, well hopefully you've taken in everything to consider and can come up with a reasonable design. I'm not seeing that design myself. Make sure you address at least these...