<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 4:22 PM Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com">hvriedel@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote:<br>
<br>
[...]<br>
<br>
> I have no intention of playing the "minimal dependency" game (though I<br>
> don't mind dropping data-default, which accounts for 6 of the dependencies<br>
> listed there). I will point out- as Gershom already did- that in many cases<br>
> it's likely easier to install a few extra Haskell packages than it is to<br>
> pull in OpenSSL as a dependency, especially on Windows. (And that's<br>
> ignoring the fact that http-client-openssl exists.)<br>
<br>
While I do appreciate the technical issues resulting from HsOpenSSL on<br>
Windows[1], I'll be frank and admit that there's a "political" aspect<br>
that worries me with such a large number of added dependencies imported<br>
into the cabal project in one go, as that would promote (or at the very<br>
least bias) one specific family of multiple competing HTTP-client<br>
abstractions into the Haskell Platform through the back-door (assuming<br>
the idea of the HP hasn't been abandoned -- I may not be up to date<br>
regarding that debate), and make it a fait accompli without having<br>
actually had any agreement on it (which I admit may never be reached, as<br>
the associated communities involved have grown quite large by now and<br>
may disagree quite violently on basic design choices...).<br>
<br></blockquote><div><br></div><div>It may be worth looking at the reverse dependencies and download counts on this. But more importantly: I am most certainly not proposing that http-client be part of the platform. I discussed this already with Duncan last week: I have no idea why having the libraries in the platform should be necessary for a dependency of an executable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's why I suggested HTTP+HsOpenSSL (which tbh is not my favorite HTTP<br>
library), as that would be the neutral choice regarding HTTP-libraries<br>
at the foundational core library level. Alternatively, Gershom's<br>
suggestion to shell out to curl(1)/wget(1)/etc would equally achieve<br>
impartiality regarding HTTP-libraries (and probably work better on<br>
Windows too)<br>
<br></blockquote><div><br></div><div>So to translate: since there are two good libraries for doing HTTP client side calls that both have TLS support, we can use neither of them, and must instead continue using the library we know to be inferior, *and* do extra dev work to add in TLS support, an endeavor which at least anecdotally has failed once before?</div><div><br></div><div>By the way: I'm unaware of any violent disagreement around http-client vs http-streams. There are certainly differences between the libraries which I'd be happy to explore with others (in a separate thread, this isn't the place), but I think the possibility for a community brawl on this is slightly overstated.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS: We shouldn't forget that there's also an existing deployed<br>
    cabal-install user-base we can't get rid off so easily, which may<br>
    still leak unencrypted basic-auth credentials for the years to<br>
    come. Just saying...<br>
<br></blockquote><div><br></div><div>I agree on that front. I think that Hackage should turn away all uploads that aren't TLS-secured, and should make that change ASAP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 [1]: Are those issues documented somewhere btw? Could that it be<br>
      addressed via minghc?<br>
<br><br></blockquote><div><br></div><div>There's not really anything to document. It's a matter of having to install the DLLs correctly, which people find difficult without a package manager. I'm in favor of supporting this situation better with MinGHC, but it would need someone else to spearhead it; I frankly have no itch to scratch here, since I'm already quite happily using the tls package.</div><div><br></div><div>Michael</div></div></div>