Hmm, interesting approach. It would fix issues like #7368. Do you think of any downsides?

I haven't been able to think of any downsides. I tested on a good number of packages without finding any breakage.

There are only two minor things I'm still somewhat unsure of. The first is putting the python wrapper in $dir/.python-wrapped. It seems more semantically meaningful to put it in $out/bin/.python-wrapped, but I'm not sure how this would interact with multiple invocations of wrapPythonProgramsIn, and it would require me to ensure that the bin directory actually exists. For these reasons I'm leaving the current implementation alone unless anyone has a better idea. Since the file is hidden anyway, the ugliness of putting it in $dir (which is usually $out) is not too egregious.

The second thing is the handling of EGG-INFO scripts. Should I be skipping them? Do they need to have their shebangs patched in some way?

Other than that, I believe this is ready for a merge. I think it's significantly simpler and more robust than the current approach.

Resolved conflict with current master.

I've updated this to master and re-tested it, but am now running into shebang lines which are too long. I'm not sure why I didn't encounter this problem last time I tested it, but regardless this is a problem that could be fixed by #11133, if we can't find another approach.

Any idea how this would work with alternative interpreters like IPython/Jupyter?

@FRidh Perhaps I don't understand the question, but I can't think of any way this would impact IPython/Jupyter use, since this PR only effects executable python scripts.

If I understand correctly you will wrap the Python interpreter, and patch the shebangs of all scripts in say /bin to use the patched interpreter.

However, IPython/Jupyter resides also in /bin, and being an alternative interpreter, needs to be able to import modules in a similar way as CPython, which is currently broken when using python.buildEnv, but not when using nix-shell though). See #11147. I'm trying to see whether and how work here relates to that. If I am correct I can't just wrap everything in /bin in case this PR would get merged.

this is broken in the same way that the current wrapping mechanism is broken,
it leaks python-path to sub-processes, that may have a different oath and/or python major version

@FRidh would you test this with jupyter?

@FRidh is this still relevant? If I'm informed correctly, the python infrastructure has changed significantly since this PR was created, so perhaps we can close this? Even if it is closed, the diff will stay if anyone would like to look at it later.

@bennofs you're right, let's close this.