FAQ - (Not So) Frequently Asked Questions

I don’t know any bash or Python, can I still use $language with pave?

Yes, (although learning some sh or bash is recommended), it is easy to use another language with pave (like it is done with ansible).

The basic idea is this... that you write a script, upload it to your host, and then run it there:

    - packages:
        install: other-runtime          # if need-be, or

    - scp: put setup_script.pl /tmp/    # to use perl
    - /tmp/setup_script.pl --kapow

How can I make pavefile authoring easier?

  • Use a professional text editor which can highlight yaml. If you are just starting out you might try Geany on Linux, Notepad++ on Windows, or TextMate2 on OSX. Make sure to set it to indent with spaces, not tabs.

  • Make judicious use of pave’s command-line parameters. See the Command-line Reference on usage.

    • Turn on the debug logging option -V to see how the yaml parser has interpreted the given text and many other details.

    • Likewise, use the test option --test to parse and validate the file while skipping execution.

    • -i/--interactive is good for stepping through execution of tasks.

    • -s/--select is great for testing each task as you write it:

      pave -s -1 -V

      Yes, that second parameter is a negative number one, signifying the last task. This is really helpful–you won’t have to wait while multiple previous tasks are checked again.

    • -o/--option or -v/--var options can be used to set values, variables in the pavefile:

      pave -o /main/inspect sh

What about troubleshooting?

  • See answer above.

  • In addition to the verbose command-line parameter, debug text and exception tracebacks, etc, for the last five runs are typically recorded in:


    This location may be different on your machine, or if you are using the XDG_CACHE_HOME environment variable.

  • Regexes:
    grep -E/egrep is used extensively on the remote-end when searching. For whatever reason it doesn’t support \d, so don’t waste hours debugging like I have. :/

Why the % variable expansion syntax? ——————————————~

Originally pave used Python’s newer, niftier string format syntax {name} rather than the older printf-style substitution %(name)s as it is more readable and sophisticated. Unfortunately though, after writing a few pavefiles it became clear it was too much trouble.

Why? First, it conflicts with yaml mapping syntax. Not the end of the world you might think, it can be quoted... ok. Ooh, it conflicts with bash at times too, braces are used for many substitutions... uggh, ok. Went to add {{ Jinja }} support and kaboom!, the last anvil to break the camel’s back. To escape braces in string.format syntax you need to double them, just what Jinja uses.

Attempting to use thse features together reminds me of the old driver’s-ed film “Red Asphalt”. Time to admit defeat on that front.

Printf-syntax on the other hand collides much less often. The % character is used for an esoteric feature in YAML that pave disables. I’ve found but a few scatted shell commands like find and stat that use them. Escaping is easy though, just double it, %%, no matching front and back (with different symbols) to worry about.

Finally pave has moved to even simpler shell-style syntax as implemented by Python’s string.Template. To avoid collisions with Unix shell $variables however, we’ve kept percent as the expansion character.

There may be other exceptions, but one I can think of is Windows and so I’ve left a -b command line option to use brace format syntax instead.

What licensing is available?

pave is licensed as GPLv3+.

A commercial-friendly license may be available for a fee. Support/fixes/features might be offered for a fee as well, regardless of license.

What are your thoughts on the subject?