Working through adding windows support for pex. It...
# general
k
Working through adding windows support for pex. It seems to be a common theme that one of the most pervasive issues is the location of the python executable. One of the specific location issues I am focusing on now is the hashbang that seems to be every where 
#!/usr/bin/env python
 something that will never resolve in windows.  It's even part of the tl/dr ! https://pex.readthedocs.io/en/latest/whatispex.html#tl-dr That raises some questions:   For window support would we be willing to (just for windows users) drop the idea of being able to execute a .pex file alone. Example: https://github.com/pantsbuild/pex/blob/master/tests/tools/commands/test_venv.py#L533 changing to 
subprocess.check_call(args=[sys.executable, "-mpex", pex_file, "venv", venv], env=make_env(PEX_TOOLS=1))
And then in general, are we ready to have different paths in a few places the code base with a few 
if WINDOWS
 statements that will be required to achieve first party support for windows?
Also makes me start thinking, can there be the idea of two different levels of support. Building a pex file, vs running a pex file.
Oh, I did find this: https://www.python.org/dev/peps/pep-0397/#shebang-line-parsing after posting this message.
h
Working through adding windows support for pex.
Woot, thanks! Check out the #pex channel also
For window support would we be willing to (just for windows users) drop the idea of being able to execute a .pex file alone.
What would be the purpose of Pex here? I get the general notion of "I want to bundle all my deps and code into a single file", but then I don't know how users would end up actually consuming that file
Also makes me start thinking, can there be the idea of two different levels of support
Generally, I think we'd be pretty hesitant to do this. It greatly adds to complexity to have to keep track of which functionality maps to what. And it's confusing for users to know what can and cannot be used For example, if we hooked up Windows-compatible Pex to Pants via
pex_binary
, what would Pants do if a user tried to set a field like
zip_safe
that (for the sake of argument) does not work on Windows because it's tier 1
w
the PEP linked to by the “what is pex” page does actually have some useful mentions of windows: https://www.python.org/dev/peps/pep-0441/
@kind-knife-49817: maybe you can confirm whether those file-extension associations actually ended up landing in the Windows installer for Python?
c
I think what we need to figure out is what Windows support for pex actually means. Will a single pex file be portable between platforms or does it need to built in a different way to run on a windows box? Or when you run it on windows do you need to always call it via
python.exe
. That will help guide how we approach the problems we are seeing in the tests.
1
k
Posted a follow up to some of this in the #pex channel.