Stop using the HTTP package. #7456
Conversation
We only depend on the urlEncode function in the package, which is also provided by http-types. The HTTP package also depends on the network package, which has difficulty building on ghcjs.
|
Unfortunately this is not the only transitive dependency on network in pandoc (cabal-plan will give you a nice graph). |
|
Even so, avoiding a dependency on HTTP seems a win. |
Yeah, I'm planning to spend more time working on removing the network dependency (or fixing it so it builds on ghcjs). Another issue is how everything depends on zlib; my guess is we need to add a bunch of functionality to https://github.com/GaloisInc/pure-zlib in order to use it as a drop-in replacement for zlib, which looks pretty painful.
Sounds good! Is there anything else I should do before merging? |
pandoc.cabal
Outdated
| @@ -599,6 +598,7 @@ library | |||
| Text.Pandoc.UTF8, | |||
| Text.Pandoc.Templates, | |||
| Text.Pandoc.XML, | |||
| Text.Pandoc.Network.HTTP, | |||
There was a problem hiding this comment.
I'd prefer to make this an internal (non-exported) module.
pandoc.cabal
Outdated
| @@ -598,7 +598,6 @@ library | |||
| Text.Pandoc.UTF8, | |||
| Text.Pandoc.Templates, | |||
| Text.Pandoc.XML, | |||
| Text.Pandoc.Network.HTTP, | |||
There was a problem hiding this comment.
Shouldn't this now appear in other-modules?
There was a problem hiding this comment.
Sorry about that; fixed.
|
Thanks! |
Given ozanmakes/markup.rocks#21 and #4535, I've recently been working on getting pandoc to build with ghcjs, which I've been able to do here: https://github.com/mt-caret/pandoc-ghcjs. Unfortunately, while the build succeeds there seems to be some problems with the JavaScript emitted so it does not work as-is (I'd love some help understanding what's wrong if anybody is interested). In the meantime, there seem to be relatively trivial changes that I can upstream to make pandoc more ghcjs-friendly.
Pandoc only depends on the urlEncode function in the package, which is also provided by http-types. The HTTP package also depends on the network package, which has difficulty building on ghcjs. I've created some benchmarks and fuzzing tests (https://github.com/mt-caret/bench-url-encode), and based on the results there unfortunately http-type's implementation seems to be 50% slower.