The ZIP dialect documentation outlines the following options, where a FILE! signifies the source of data you want to compress. But it doesn't seem to have a way to specify an alternative naming or structure to your files. Whatever you are compressing has to already be laid out with the names and directories that you want the archive to compress as:
you can zip a single file:
zip %new-zip.zip %my-file
a block of files:
zip %new-zip.zip [%file-1.txt %file-2.exe]
a block of data (binary!/text!) and files:
zip %new-zip.zip [%my-file "my data"]
a entire directory:
zip/deep %new-zip.zip %my-directory/
from a url:
zip %new-zip.zip ftp://192.168.1.10/my-file.txt
any combination of these:
zip/deep %new-zip.zip [
%readme.txt "An example"
ftp://192.168.1.10/my-file.txt
%my-directory
]
(I'll also note that the /DEEP option seems it should apply to individual directories; you may want one directory to be zipped deeply and not others.)
One way of working around the naming problem is to read the data yourself; which has a downside of making you read all the files you're working with into memory at the start of the zip (vs letting it read them one at a time as it goes along, possibly even doing streaming compression):
zip compose [%new-name.dat (read %old-name.dat)]
Something seems a little tenuous to me about the pattern %filename "data" meaning the file is just a name, while %filename means the file is actually read. You could use another datatype like ISSUE! for naming, which could perhaps be seen as like a "label":
zip [#new-name.dat %old-name.dat]
But that would be awkward on the unzip side, where FILE! is a pretty clean label there:
you can uncompress to a directory (created if it does not exist):
unzip %my-new-dir %my-zip-file.zip
or a block:
unzip my-block %my-zip-file.zip
my-block == [%file-1.txt #{...} %file-2.exe #{...}]
I think it should be the case that if you zip something up, then unzip it to a block...you should be able to use the unzipped block to re-generate the same archive again with zip. That seems a pretty good design goal.
So perhaps FILE! is always a label, and @ could be used for specifying contents other than the file itself?
data: #{AEBDAE}
zip [%new-name.dat @(%old.dat) %ae.dat @data %README.md @({Hello}) %as-is.txt]
Athough plain GROUP! would be cleaner...
data: #{AEBDAE}
zip [%new-name.dat (%old.dat) %ae.dat (data) %README.md ({Hello}) %as-is.txt]
That could get confusing if using COMPOSE to put the file names in non-literally, however. If not for the limitations of ANY-WORD!, it seems this would be better as SET-WORD!
data: #{AEBDAE}
zip [new-name.dat: %old.dat ae.dat: data README.md: {Hello} as-is.txt: auto]
Anyway, the point is that today the only way to do it is if you put the filename and then COMPOSE in. I'm going to do that for the problem I'm looking at right now, but wanted to raise the question of how this might improve.