The "create a pyz of shiv using shiv" example doesn't work

As written, the example leaves the shiv pyz file with a shebang pointing at the (presumably temporary) virtual environment used to build it.

The example should probably include a -p "/usr/bin/env python3" argument to specify an explicit interpreter.

Actually, given that shiv pyz files are self-contained, there’s no real benefit to them ever having shebangs that refer to a virtualenv - maybe it would be worth making the default shebang /usr/bin/env python3, or at least locate the “base” Python interpreter for a virtualenv - which can be done as

Path(getattr(sys, 'real_prefix', sys.base_prefix)) / Path(sys.executable).relative_to(sys.prefix)

[pfmoore]

Yeah, that looks really good. Tested on Windows using virtualenv and venv and it seems fine.

[pfmoore]

Ah, yes. My mistake - I didn’t test it properly.

The problem is that you need to get from the virtualenv/venv back to the original base installation. That’s what sys.base_prefix gives you (for a venv) and sys.real_prefix (for a virtualenv). So all the getattr stuff is covering both bases there.

But they give you the equivalent of sys.prefix, not sys.executable. And the executable gets put in various places - what I was trying to do was avoid hard coding the fact that it’s in Scripts/python.exe on Windows, and bin/python on Unix. But that’s for virtual environments, and the whole point here is to get a non-virtual location. So I was being dumb. What you actually need is just

Path(getattr(sys, 'real_prefix', sys.base_prefix)) / 'python.exe`

That’s for Windows - of course, you’ll need to miss of the .exe suffix on Unix, and maybe do something about python2 vs python3 - and maybe Python isn’t even in sys.prefix, but in /usr/bin or /usr/bin/local…? Or get everyone to switch to Windows where it’s simple 😉

The more I think about it, the more I’d go for #!/usr/bin/env python3 (use “python3” or “python2” depending on sys.version_info). The Windows launcher handles that, and (hopefully!) it’s reliable on Unix.

Or maybe even do what zipapp does, and default to no shebang, forcing the user to run the pyz as python xxx.pyz or be explicit about what they want via -p.