There are a lot of places where a general hook would be really useful, and I
have a plan for how to add them to the "nest" tool that will replace
easy_install.  (Alternately, perhaps "pip" could grow the hook mechanism I have
in mind, and I could just not write "nest", since it will be doing some of the
same things.)

However, for this specific issue, I'd like to do a less ambitious fix, so as to
fix the problem while freeing up more time to work on the cleaner install tool.

OTOH, even if we did provide the hook you're proposing, it would still leave the
problem of specification.  A command-line option works for the direct "install"
case, but not for package building.

As I asked previously, are there any sane use cases for building a bdist of any
sort targeting a hardwired virtualenv path?  Or should --root always force
stripping of the virtualenv?

A general hook would be *really* useful.  Something like "--script-
rewriter=module:func".  A similar issue exists with "virtualenv --relocatable", 
which fixes up existing scripts but not new scripts (so you have to rerun it).  
If this option existed, something could be put in distutils.cfg to handle this 
generally.

This is a bit tricky.  If you're building a system package, you probably want to
strip off the VIRTUAL_ENV.  *Probably*.  But, --s-v-e-m or --root/--record
installs could also be aimed at the virtualenv, rather than being used to
package a non-virtualenv target.  ISTM that what would need to happen is to
strip the virtualenv from sys.executable by default, with an option available to
*not* strip it, in the event you're actually targeting the virtualenv.  It would
make it impossible to build an RPM, .deb, or bdist_wininst targeting the
virtualenv, however.

Ian, is there any sane use case for building a bdist of any sort targeting a
hardwired virtualenv path?  And, sane or no, is anybody *doing* it anyway?  ;-)

When running setup.py install --single-version-externally-managed in order to
package an egg in, eg, a .deb, the scripts generated from entrypoints contain a
line:
#!/path/to/python

This path is taken from sys.executable.  

However, this command is often run from inside a virtualenv, in which case
sys.executable is not what you want.

It would be nice to either:
1) be able to specify a path for the python executable on the commandline,
similar to the --prefix option
or
2) strip off the contents of the $VIRTUAL_ENV variable out of sys.executable
when running with --single-version-externally-managed