Home Original page

zipapp should not include temporary files?

Paul Moore p.f.moore at gmail.com
Wed Jul 26 18:03:07 EDT 2017 
On Wednesday, 26 July 2017 18:37:15 UTC+1, Irmen de Jong  wrote:
> when creating an executable zip file using the zipapp module, it's a little sad to see
> that no effort is done to filter out obvious temporary files: the resulting zipfile
> contains any *.pyc/pyo files and other things such as .git, .tox, .tmp folders.
> 
> The documentation says "zip is created from the contents of the directory" so strictly
> speaking it's not wrong that it is doing this. However I think it is inconvenient,
> because we either have to clean out the directory manually first before zipping it, or
> afterwards, remove stuff from the resulting zipfile.
> 
> What do you think? Should the zipapp module perhaps be improved to automatically skip
> obvious temporary files or perhaps allow to provide a filter function?

Well, the expected usage of zipapp is to prepare a clean distribution of your application and then zip it up. You're not really expected to just zip a working environment. But I guess I can see that you might do some testing after preparing the staging directory for zipping, and that might leave unwanted files around.

Allowing for a filter function seems like a reasonable suggestion. I'm a little less comfortable with guessing what's "obviously" temporary, as it's too easy to get such a judgement wrong. For example, why do you consider .pyc files as "temporary"? Someone might want to precompile the contents of a zipapp.

If you want to create a feature request for a filter function on bugs.python.org and assign it to me, I'll take a look at it. It would only be available from the Python API, though, and only if the source is a directory (not if it's an existing zipfile, as those are simply copied as binary data). I don't think it's worth trying to design a command line API for this - parsing a "what to exclude" spec would significantly increase the complexity of the module for limited benefit.

Paul.
More information about the Python-list mailing list