Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move libyaml into a separate library #145

Closed
sol opened this issue Aug 14, 2018 · 9 comments

Comments

@sol
Copy link
Collaborator

commented Aug 14, 2018

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

This comment has been minimized.

Copy link
Owner

commented Aug 14, 2018

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

@sol

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 14, 2018

Yes, that is what I mean.

@sol

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 14, 2018

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

@snoyberg

This comment has been minimized.

Copy link
Owner

commented Aug 14, 2018

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

This comment has been minimized.

Copy link

commented Oct 8, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 9, 2018

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

@afranchuk

This comment has been minimized.

Copy link

commented Oct 10, 2018

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

This comment has been minimized.

Copy link

commented Oct 10, 2018

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.

afranchuk pushed a commit to afranchuk/yaml that referenced this issue Oct 10, 2018
afranchuk pushed a commit to afranchuk/yaml that referenced this issue Oct 10, 2018
@snoyberg

This comment has been minimized.

Copy link
Owner

commented Oct 11, 2018

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

@snoyberg snoyberg closed this in 1e655f0 Oct 12, 2018

snoyberg added a commit that referenced this issue Oct 12, 2018
Merge pull request #160 from afranchuk/master
Close #145. Create a separate libyaml package.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.