__PYVENV_LAUNCHER__ not considered when cross-compiling

Originally reported by: commodo (Bitbucket: commodo, GitHub: commodo)

Well, maybe I did not formulate this too well.
Context: we're cross-compiling python-setuptools for OpenWRT, and we're using the PYVENV_LAUNCHER to create/cross-compile scripts (easy_install and pip) to have "#!/usr/bin/python2.7" in the script header rather than the host python (which is in a build path like /home/x/work/openwrt/staging_dir/host/bin/python2).

It seems that the command/install_scripts.py file provides and executable path for python, which happens to be the host python.
That means, that when the target setuptools is built, it will try to run the python at that long build path and won't work.

Not sure what the best fix is, but for now, we're patching (in OpenWRT) with this (check below please):
https://github.com/commodo/packages/commit/b9a0a650352684d8111758c5381c2853585b2015

This worked for python-setuptools up to a point ; can't be sure when this changed, since I am not comfortable with Mercurial (i.e. I was lazy to dig deeper in commits).
This is our current fix, but we'd like an official upstream version.

Thanks :)
P.S: while I'm reporting this, maybe I'll try to see why I added this patch as well:
https://github.com/openwrt/packages/blob/master/lang/python-setuptools/patches/0001-remove-windows-support.patch
It was added some time ago and I forgot why.

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/424

Start with command/install_scripts.py and compare its executable-path handling with the linked OpenWRT patch. Reproduce the cross-compilation case involving PYVENV_LAUNCHER, then verify that generated easy_install and pip scripts use the target interpreter path rather than the host build path.