On Windows, build is broken

[smaudet]

sys.executable is nonsensical ( == None).

This causes some fun breakage in distutils. The shim fix is to manually modify distutils to point to the path of sys.executable every time it is called - but perhaps this should be configurable inside Jython itself.

The proposed fix would provide e.g. a -Djython='jython-name' parameter to the jython startup, which would then be queried via Jython with:

sys.executable = subprocess.check_output(('where','jython-name').replace('\r\n','')

And then have sys.executable set transparently for the distutils (and other) packages.

Currently this requires one manual modification to the ez_setup.py and two modifications to the distutils package (build.py @ 118 && sysconfig.py @ 30)

[jimbaker]

Some additional notes to think about; I don't have a comprehensive solution yet in mind:

Per http://docs.python.org/2/library/sys.html#sys.executable:

A string giving the absolute path of the executable binary for the Python interpreter, on systems where this makes sense. If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None.

For Jython, sys.executable is normally set by the startup script for Jython (for Windows, jython.bat; for other platforms, the jython shell script) by using the Java property python.executable, eg -Dpython.executable=/path/to/jython When PySystemState is initialized, PySystemState#initExecutable in turn verifies this path of the executable, and if the executable file exists, sets sys.executable to the abspath of this file, otherwise None.

So I would expect this to work under normal distutils/setuptools-based usage, because that should be invoked by using the Jython script (eg jython setup.py), and not directly invoking the jar. If that's not the case, clearly this is a bug.

Another consideration. Regardless, packaged standalone jars, as produced by Clamp's singlejar command or the installer, should be able to refer to themselves with sys.executable, and they should be movable. Something like the following answer should suffice: http://stackoverflow.com/questions/320542/how-to-get-the-path-of-a-running-jar-file

Such self reference is more difficult to square with run.py support enabled, but there potentially could be some workaround for this, possibly a special env var to override. Not certain how to do this in a clean fashion.

Somewhat related to this bug: http://bugs.jython.org/issue1069

[smaudet]

'Another consideration. Regardless, packaged standalone jars, as produced by Clamp's singlejar command or the installer, should be able to refer to themselves with sys.executable'

This is not actually true, though, the system is unable to ascertain how it was invoked (namely, what batch script and set of parameters were used).

For singlejars, (which are intended to be run via java anyways), it is also necessary to specify this sys.executable parameter, as it is possible to invoke without running java -jar, if you intend to make use of it.

As -Dpython.executable seems to work reliably, the fix is to:

A) Either provide make.bat and make.sh scripts to pass in the parameter

B) Add documentation to the README and INSTALL which specify this parameter and its value.

Beyond the install scripts (running jython setup.py install on clamp), perhaps it would be good to test that the parameter is passed around during Java/Python bridging/proxying.