[bugstomper]

I encountered a strange problem while working on a plugin and I'm not sure if it indicates a bug in Calibre or just something to look out for or do differently.

I had two library packages embedded in the plugin zip. One of them uses os.path.dirname(__file__) to get the path of a resource file in the package's directory that it reads at runtime. Debugging logging showed me that in normal operation __file__ has as its prefix the path to the plugin's zip file, and the package has no problem with the I/O routines reading from it that way.

When I added the second library package to the plugin's tree, I found that in the first package __file__ now contained a path in a temporary directory on disk, one which did not exist at runtime, As a result the attempt to load the resource file failed.

Experimenting, I found that for some reason the second package contains a file with extension .so. Even without that library, if I simply create any file with a .so extension in its name, anywhere in the plugin zip directory tree, with any contents even zero length, then Calibre loads the plugin in such a way that __file__ is a temporary directory that does not exist at runtime instead of being a path to the zip file.

I saw this on Calibre 5.8.1 and still see it on 5.9, on macOS Catalina. I haven't tried Windows or Linux. Does Calibre have a heuristic in which it unzips some plugins if it sees it has certain file types such as *.so which maybe can't be used from a zip? Are there some uses of __file__ that a python library might use but could break when the library is used in a plugin?