Add support for parsing YAML metadata.

[chriskrycho]

It appears this is essentially an alternative implementation of @zackw's work in #3, which I only saw after submitting the PR.

Cleary this is a desired feature. 😉

[liob]

I have been pushing this issue on my todo list for a long time. @zackw, I am sorry for that.

The truth is, I really dislike all implementations presented so far. I do believe that metadata and content processing should be splitted up in different tasks in pelican. However, this will not hapen in the near future and there is a clear need for YAML support.

Therefore, I am asking you @zackw and @chriskrycho, which implementation do you like best?

I would favor @chriskrycho implementation. In my opinion it is not as elegant as @zackw's #3 but it is clear to read and does not use regex. I really dislike #4 conceptually.

[zackw]

I understand why you might not like #4 -- I'm not super happy with the output filter thing myself -- but it achieves something that can't reasonably be done any other way: it interprets Pandoc-flavor Markdown inside text fields in metadata. This is an essential feature for the site I am using this for (https://readings.owlfolio.org/), so if you reject that approach I am going to have to maintain a fork indefinitely 😞 I am having a conversation with the Pandoc maintainers about adding a less clunky way to extract the metadata; see jgm/pandoc#2019 .

I am indifferent between #3 and #5 since I would have to continue with #4 regardless; however, if you go with #5, please merge at least the documentation I wrote (corrected for not aligning the "plain" metadata syntax with Pelican core) and the mechanism for only loading PyYAML if required (this is critical for backward compatibility with sites that don't expect PyYAML to be a dependency of this plugin).

[chriskrycho]

Note that I do align plain metadata with Pelican core and gracefully degrade if PyYAML isn't available in #5—I agree that #3 is more elegant; I just wanted to be clear that this does not fall down on normal metadata. That said, I'd be happy to integrate some of the better/more elegant features of the #3 solution into my own PR along the way (probably this upcoming weekend).

I've been following @zackw's conversation with the Pandoc folks at jgm/pandoc#2019 as well, and I think ultimately we want to replace any of these solutions with that; hopefully it won't be too long in coming.

[liob]

I would prefer not to splinter the development. Therefore, I will merge pull request #4 when it is ready. However, this will only be a temporary solution. When jgm/pandoc#2019 is concluded, the code will be removed. I hope that this is a good solution for everyone.

[chriskrycho]

That seems eminently reasonable to me. Hopefully jgm/pandoc#2019 will get resolved in the next release of Pandoc!