# How can I optimize the arara (un)zip-program?

I have written

zip.yaml - it works as I can see.

!config
# zip rule for arara
# author: cis
# version: 0.1
# requires arara 3.0+, zip
identifier: zip
name: Zip
command: <arara> @{unzip}@{program} @{options} @{outputpath}@{name}.@{extension} '@{data0} @{data}' @{encrypt} @{pw}
arguments:
- identifier: unzip
flag: <arara> @{ isTrue( parameters.unzip , "un" ) }
- identifier: program
flag: <arara> @{parameters.program}
default: zip
- identifier: options
flag: <arara> @{parameters.options}
#  default: ???
- identifier: outputpath
flag: <arara> @{parameters.outputpath}
- identifier: name
flag: <arara> @{parameters.name}
default: archive
- identifier: extension
flag: <arara> @{parameters.extension}
default: zip
- identifier: data0
flag: <arara> @{parameters.data0}
default: <arara> @{getBasename(file)}.pdf
- identifier: data
flag: <arara> @{parameters.data}
- identifier: encrypt
flag: <arara> @{ isTrue( parameters.encrypt , "--password" ) }
- identifier: pw
flag: <arara> @{parameters.pw}


A simple test-program:

% arara: pdflatex
% arara: zip
\documentclass{article}
\begin{document}
Hello world.
\end{document}


Lets test the unzip-part!

Especally this works (run in this order):

% #arara: pdflatex
% #arara: zip: { name: archive2 }
% arara: zip: { unzip: true , name: archive2 }

\documentclass{article}
\begin{document}
Hello.
\end{document}


Now to the problem:

If the zip-archive got a password, I could not run zip.yaml to it's end :(

% #arara: pdflatex
% #arara: zip: {  encrypt: yes , pw: aaa }
% arara: zip: { unzip: true }
\documentclass{article}
\begin{document}
Hello World again.
\end{document}


What can I do? Thank you!

• Wow, you are using arara way more than I do. :) So far your rule looks very nice, I might need to investigate for further improvements. By the way, in the new version (still in development), the YAML format will be dropped in favour of a (way) better, cleaner and easier way of writing rules; it won't be difficult to port the existing rules to the new format and also make use of the new features. :) I decided not to add a compatibility mode with old rules because I'm afraid we might benefit more by moving to cleaner things. Stay tuned, good news will come! :) – Paulo Cereda Jul 24 '14 at 20:27
• Excuse me, but I am very sceptical about 'not to add a compatibility mode'. There are worldwide lots of rules, users wrote for themself. It could become a burden (stab), when they will realize, that whose rules never run in v4.0. In my opinion, the best way would be, to put v3 and v4 together, not for using the old syntax, but to run (own) good old rules ;) [Let me give you an example - matheplanet.de/matheplanet/nuke/html/viewtopic.php?topic=194815 - o.k., it is german, but I think, the codes will speak for themself. – cis Jul 24 '14 at 21:12
• I understand your point of view. :) Sadly, as things are right now, a compatibility layer wouldn't be feasible, it brings a huge complexity which I'm trying to avoid. Rest assured I won't upload the new version to CTAN any time soon to give enough time for users to experiment things and I also for me to collect feedback. I might even write a converter for old rules. I understand your skepticism, but I really have strong reasons to change the format. I'm in the chatroom, just ping me and I can explain a little better. Well, I won't do any crazy things without hearing the userbase. :) – Paulo Cereda Jul 25 '14 at 10:17
• I might even consider the possibility of forking the project, so our beloved users won't suffer from migration. :) And of course, update the current tool. :) – Paulo Cereda Jul 25 '14 at 20:14