Support custom config files from CLI

[ashmaroli]

Fixes #321

When you provide an array of config files via the --config switch, we'll read and write to the first of such files.

• add code
• test code

[benbalter]

What's the desired user experience here? To only be able to modify the first configuration file? Would it make more sense to abstract configuration into configuration files? How often do we think users will want to modify secondary configuration files? IIRC having a singular configuration file was a purposeful design decision to keep things slim (but that doesn't mean it can't be changed now if there's a strong reason).

[benbalter]

Rather than monkey patching another method, can we pass the options hash to our existing monkeypatch?

[ashmaroli]

I couldn't find another way to bypass this deletion

[benbalter]

Could this be simplified to an attr_accessor?

[ashmaroli]

I was under the impression that when we define an attr_accessor, its called again via #initialize method

[ashmaroli]

What's the desired user experience here?

Primarily, to be in sync with existing Jekyll functionality and be able to edit the site built/served with the specified configuration file.

--

To only be able to modify the first configuration file? Would it make more sense to abstract configuration into configuration files?

When the user builds/serves via a list of config files, its understood and documented that the effective config hash will be a merged singularity. But instead of displaying contents of all the config files in the list, we shall simply allow writing to the first of specified config files.

--

How often do we think users will want to modify secondary configuration files?

Jekyll's build options allow one to specify custom config files. JekyllAdmin's UX gets hampered when we turn a blind-eye to an existing long-standing core functionality.

--

IIRC having a singular configuration file was a purposeful design decision to keep things slim (but that doesn't mean it can't be changed now if there's a strong reason).

For initial release, that was a wise decision. But its time to expand the scope.. 😁

[ashmaroli]

I believe this is ready a final review..

[ashmaroli]

Update: This will not work on Jekyll-3.5.0. Expecting refinements from Jekyll itself..

[ashmaroli]

@mertkahyaoglu @benbalter Guys, I believe this is once again ready for a scrutiny..
I temporarily disabled a Rubocop check to have it handled as required in a separate PR..