Document handling of platform-specific binaries

[pfmoore]

(Original discussion in pypa/pip#5355).

Unlike "conventional" zipapps, it seems that shiv adds bootstrap code to unpack the archive and run it from an unpacked directory. This allows it to support compiled extension modules, but it also means that the unpacked archives get left around (at least on Windows, as you can't delete a loaded DLL in Windows, and I believe the code doesn't even try to tidy the unpacked archive up anyway).

I think this behaviour should be documented, at least in the "gotchas" section of the readme, as it's likely to be unexpected for at least some users (and may even be a privacy concern for some).

It would be nice if the tool only unpacked when needed, and warned when building an archive that needed unpacking. But I doubt that's possible in practice (it's essentially the "zip safe" flag that setuptools tried to implement for eggs, that is generally considered to have failed).

[lorencarvalho]

I have a personal todo to clean up the documentation (which as you can see, is currently worthless), I'll definitely include a "how it works" section to describe this behavior.

Regarding only unpacking if necessary, in theory I totally agree, and we spent a decent amount of time trying to make zip safety work. Barry even wrote a shared object loader class that would temporarily extract .so files so they could be imported... but the reality is too many libraries expect a real filesystem (building paths off __file__ , etc) and breakage can occur in unexpected ways so we opted to just drop it and always extract.

I'll get started on building the docs up and close this issue once I have a PR!

Thanks!!

[warsaw]

Re: __file__ - that's why everyone should promote importlib.resources far and wide! Just Say No to pkg_resources and direct access of __file__.

[pfmoore]

100% agreed. Apart from C extensions, there's no reason for packages to not work from a zip file these days. Filesystems are so 1990's :-)