On 21 May 2017 at 07:29, Radon Rosborough <radon.neon@gmail.com> wrote:
>> The current behaviour fails, as you note, but it does so in a
>> "standard" way - shebang behaviour (and its limitations) is
>> well-known.
>
> I agree with this, but in my opinion the shebang is simply an
> implementation detail of virtualenv. I would like to quote @JDLH from
> [1]: "There is nothing about the value provided by virtualenv that
> demands it use the shebang." If the shebang were fundamentally
> necessary to provide the functionality of virtualenv, it would make
> sense for virtualenv to inherit the shebang's restrictions. But this
> is not the case, so I think that the shebang should be considered an
> implementation detail that the end user should not need to be aware
> of.

I agree with this way of looking at the problem, so my perspective would be:

1. Don't change anything on Windows (since that already uses the
custom 'py' dispatcher)
2. Don't change anything for cases where platform provided shebang
dispatch is trusted to be correct (i.e. no quoting of the shebang line
is needed)
3. Change the cases that currently quote the shebang line to instead
invoke a custom dispatch script running in /bin/sh

I also agree that distlib is the right level to implement the change -
this isn't about people wanting custom behaviour, it's about distlib's
default dispatch mechanism having been found not to work in certain
cases, so it makes sense to automatically switch to an alternative
that *does* work.

The custom dispatcher doesn't need to solve 100% of the currently
failing cases - it just needs to solve some of them, and provide a
foundation for future iterations on the design and implementation to
handle more.

Cheers,
Nick.

P.S. I was originally going to ask "Can we use Python to implement the
dispatch instead?", but then realised there are actually lots of messy
complications with that around getting program metadata and
environmental details right that sh deals with natively. So /bin/sh is
a better way to go.