Allow for seperate design and rendercv settings from the CV data.

[kiyose]

It would be helpful to be able to quickly switch between themes when looking for one that works.

Allowing for a separation of display instructions from the data layer would solve this and can be done by creating a file for each of the top level keys in the CV file definition.

Currently the input file looks like this:

cv: # Content
  name: John Doe
  sections:
    test_section:
    - this is a text entry.
design: # Layout
  theme: classic
rendercv_settings: # Runtime Instructions
  render_command:
    dont_generate_html: true

Splitting these sections into their own individual files allows for quicker iteration and options. With this, a person can try multiple themes quickly without having to edit any files and can also apply the same theme options to multiple CVs w/o having to copy and paste. Additionally common options can be kept easily between runs. One might generate a CV only infrequently and trying to remember all the flags passed to the render command would be hard to keep track of.

The files described here are:

input_file.yaml

cv: # Content
  name: John Doe
  sections:
    test_section:
    - this is a text entry.

design_settings.yaml

design: # Layout
  theme: classic

rendercv_settings.yaml

rendercv_settings: # Runtime Instructions
  render_command:
    dont_generate_html: true

The render command would allow for mixing and matching of these files. In this case using the classic template and a preset of render settings that turns off html, md and html file generation.

rendercv John_Doe.yaml  --design-settings classic_template_design_settings.yaml --rendercv-settings-path only_pdf_rendercv_settings.yaml 

or with settings for sb2nov theme and a preset that changes the output directory to a different location.

rendercv John_Doe.yaml  --design-settings sb2nov_template_design_settings.yaml --rendercv-settings-path outfile_rendercv_settings.yaml 

Settings would render in this priority
cmdline > file > defaults

Users could continue to use the single file input_file.yaml definition if they wish.

PR #220 is an implementation of this.

[sinaatalay]

This issue has been resolved with #220.