long paths causes update to change shebang lines

[StefanKarpinski]

Due to conda/conda#3999, implemented here:

https://github.com/conda/conda/blob/49cc9ff6faf43759c77afbd66c46c8838da635e6/conda/core/portability.py#L153-L167

Problem: if the path to the Conda.jl installation is moderately long (such that the path to its python binary is ≥ 126 (so ≥ 128) with the #! on the shebang line of a script), then conda will replace over-long shebang lines with #!/usr/bin/env python so the system python is called instead of its python; hilarity ensues.

I encountered while working on Pkg3, and worked around it: JuliaLang/Pkg.jl@d9f70b8. However, perhaps we should defend against this situation here as well. Some options:

1. Detect that the shebang line will be too long and print a warning so the user is at least aware of the potential problem.
2. Instead of calling conda as a binary and letting the OS find a python interpreter, invoke the conda script with an explicit interpreter: /path/to/Conda.jl/deps/usr/bin/python /path/to/Conda.jl/deps/usr/bin/conda $args.
3. Put /path/to/Conda.jl/deps/usr/bin in ENV["PATH"] while executing conda so that executables in that directory will take precedence and #!/usr/bin/env python will actually invoke the right python.

We could do all of the above for defense in depth. The warning is good to have, just in case. Explicitly invoking the right python seems like a good idea in general. If conda itself ends up calling some program by name without an explicit python interpreter prefix, then having the right directory in the PATH will make sure that works correctly as well.

[isuruf]

I think 3 is the easiest.
Does 2 work in windows? On unix, 2 might not work in the future if conda becomes just a script.

[StefanKarpinski]

They're all pretty straight-forward to implement. I don't think shebang are a thing on Windows, so I suspect this is a non-issue there in the first place. AFAIK, conda already is a script. Did you mean "if conda becomes a binary executable"? If so, sure, that would break this, but the breakage would be quite obvious and we could just work around that by detecting whether conda is a script or not and changing how we call it accordingly. If conda isn't a script, then the whole problem goes away.

[stevengj]

Seems to have been fixed upstream?