Support configurable (and matching) compression level in zip and deflate

[otherjoel]

The EPUB standard requires that the mimetype file in an OCF zip container not be compressed. I've been using system commands to build these containers, but due to cross-platform issues (otherjoel/perfect-edition-pollen#1) it would be nice to be able to build a valid zip container with Racket code.

Currently neither the zip function nor the deflate function provide a way for callers to adjust the compression level from a hardcoded default, but the underlying code seems like it would be able to use any valid value (0–9) if one was provided.

Additionally, this hardcoded default appears to be mismatched between deflate (which always uses 6) and zip (which always uses 8 for the metadata). This might be harmless, or maybe I’m reading it wrong, but if it is incorrect it could be fixed as part of this issue.

If you prefer, I could try my hand at adding a PR with tests/docs to add an optional argument to both functions.

[LiberalArtist]

I would also find it very useful to be able to build zero-compression ZIPs!

[otherjoel]

As I’m digging into it, I realize that being able to specify the deflate compression level doesn’t fully cover my immediate need. EPUB zip containers have to include the mimetype file at zero compression; that file also has to be the first one in the archive; and it is desirable for the rest of the files to be compressed normally. So what I really need, in addition to being able to set the compression level, is to be able to specify the order of the files in the zip container as well as separate compression levels for certain files.

The cleanest interface for the above would be to add an #:exists parameter to zip that allows appending to an existing zip file, but that will take me a while (I wasn’t planning on becoming a zip file format expert). A quicker way would be to add a zip-entry struct that consists of a pathname and a compression level, and an alternative function that works like zip but, instead of paths, accepts a list of zip-entry structs and provides guarantees about preserving the order of the entries in the zip archive.

Any opinions?

[LiberalArtist]

A quicker way would be to add a zip-entry struct that consists of a pathname and a compression level, and an alternative function that works like zip but, instead of paths, accepts a list of zip-entry structs and provides guarantees about preserving the order of the entries in the zip archive.

I think it would be very useful to have a zip-entry struct analogous to tar-entry. In particular, tar-entry lets you create a tarball without having to create a corresponding directory tree on the filesystem, which avoids all sorts of potential headaches.