Move libyaml into a separate library

[sol]

My main motivation for doing this is to improve hackability by making it easier to use ghci during development.

@snoyberg would you accept a patch?

[snoyberg]

You mean a separate library for the low-level C bindings exclusively, or something else?

[sol]

Yes, that is what I mean.

[sol]

Ah yes, I see, actually I was not very specific, I'm talking about Text.Libyaml and the the bundled C sources.

[snoyberg]

I'm not in favor of adding an extra package to the mix for this purpose. What about using the --flag yaml:system-libyaml flag?

[afranchuk]

If this is pertaining to separating the Text.Libyaml module, that may be useful since that removes a lot of dependencies (e.g. there's no reason someone who just wants to do raw yaml processing should need aeson). At a glance, it looks like Text.Libyaml only uses conduit, bytestring, unix, and maybe filepath?

[snoyberg]

That's a stronger reason for this IMO. I'd be open to a PR on those grounds.

[afranchuk]

Do you imagine the separate packages being in separate directories, or just separate packages at the top-level? I'm not all that familiar with hpack, but I think it only allows one package.yaml (which maps to one cabal file and library) per directory, so if you want to continue to use hpack I think they'd have to be separated. Otherwise I think two cabal files at the top-level would work, too.

Would/should the libyaml version number remain the same as it is now? Or should it get a fresh version number? I think a fresh number makes sense since it will be a new package, and will proceed forward and change its version number separate from yaml.

[afranchuk]

Since yaml is the primary package, would you prefer only moving the libyaml stuff into a subdirectory (and keeping the yaml code at the top-level)? That would reduce the number of folders and files that will move around, seeing as the executables and tests are all for Data.Yaml.

[snoyberg]

Good questions, I'll add feedback on the PR itself. Thanks 👍