On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote: [...]
I have no intention of playing the "minimal dependency" game (though I don't mind dropping data-default, which accounts for 6 of the dependencies listed there). I will point out- as Gershom already did- that in many cases it's likely easier to install a few extra Haskell packages than it is to pull in OpenSSL as a dependency, especially on Windows. (And that's ignoring the fact that http-client-openssl exists.)
While I do appreciate the technical issues resulting from HsOpenSSL on Windows[1], I'll be frank and admit that there's a "political" aspect that worries me with such a large number of added dependencies imported into the cabal project in one go, as that would promote (or at the very least bias) one specific family of multiple competing HTTP-client abstractions into the Haskell Platform through the back-door (assuming the idea of the HP hasn't been abandoned -- I may not be up to date regarding that debate), and make it a fait accompli without having actually had any agreement on it (which I admit may never be reached, as the associated communities involved have grown quite large by now and may disagree quite violently on basic design choices...). That's why I suggested HTTP+HsOpenSSL (which tbh is not my favorite HTTP library), as that would be the neutral choice regarding HTTP-libraries at the foundational core library level. Alternatively, Gershom's suggestion to shell out to curl(1)/wget(1)/etc would equally achieve impartiality regarding HTTP-libraries (and probably work better on Windows too) PS: We shouldn't forget that there's also an existing deployed cabal-install user-base we can't get rid off so easily, which may still leak unencrypted basic-auth credentials for the years to come. Just saying... [1]: Are those issues documented somewhere btw? Could that it be addressed via minghc? Cheers, hvr