I have a Python PEX built using Pants 1.0.1. This PEX is a working python application, up until ubuntu 16.04 and fedora 24 released using python 2.7.12. Now I get an error indicating that the encoding of the PEX file is bad:
$ ./ainfo_py.pex
File "./ainfo_py.pex", line 2
SyntaxError: Non-ASCII character '\xe4' in file ./ainfo_py.pex on line 3, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
Duh. The zip file is embedded within the .pex file, so naturally there will be non-ascii characters in the file.
Reading the link in the error message, it says I can put an encoding at the top of the file, however, I don't think there is an encoding that would fix this, is there?
I'm not sure what to do at this point. It seems to me that python 2.7.12 broke PEX. Is there an update to pants that fixes this? Is there something I can add to the pex file to fixes this?
Edit
A little more information. I'm not sure why this ends up being important, but it seems that it does. I modify the PEX file slightly after it is built. I change the shebang at the top of the file from python2.7
to python
. I want to be able to run the same PEX on both python 2.6 and 2.7 versions, based upon whatever version is available on the variety of distributions this needs to run on. It appears that if i leave it alone, as python2.7
it works fine on python 2.7.12. If i change it, it no longer works. The default python on Ubuntu 16.04 is still python 2.7, so why would changing python2.7
to python
make a difference?
More Information
If I unzip the PEX, I can execute the directory and I would expect to. So I remove the first line of the PEX file, which has the #! in it, the rest is a zip. I uncompress the zip into a directory called unzipped. I can then execute python unzipped
without issue. So the encoding of the source files themselves doesn't seem to be an issue. I cannot execute the zip directly. I get the same error when running python unzipped.pyz
.
My Solution
So there is no really good answer to my problem here. Since I modify the resulting PEX to remove the python2.7
requirement and change it to python
, to allow it to run on python 2.6 or 2.7 depending on the distribution, I'm finding that its the modification of the PEX that is causing the problem. So I've resorted to making 2 PEX files, one for python 2.7 and another for python 2.6.
In the end, I do not understand why simply touching the #!
at the top of the PEX causes python to no longer understand what that file is. Maybe someone could shed some light on why that is.