Making cabal-install SSL capable

[Thomas Tuegel]

On Thu, Apr 30, 2015 at 5:12 AM, Yitzchak Gale <gale at sefer.org> wrote:
> Both extra Haskell dependencies and C dependencies are a
> problem for cabal-install.
>
> The reason is that cabal is a basic requirement to
> bootstrap a Haskell installation from scratch. So either of those
> will make life very much harder for distro packagers, builders
> of Haskell Platform or other such from-scratch installation
> options, and anyone who needs to get a Haskell
> tool chain installed on a platform that is non-standard in some
> way.

Michael is putting together some tools for us that should make added
Haskell dependencies a non-issue from the standpoint of distributing
cabal-install. We already have a bootstrap script for this purpose,
but the new tools should make it more robust. So, I don't think we
should continue to be concerned by that aspect of additional Haskell
dependencies.

> In summary - I vote for cabal-install-basic with no C deps,
> very minimal Haskell deps, possibly stripped-down cabal
> functionality if needed, and a simple SSL shell-out option designed
> for maximum portability. And then, one or more full-featured
> cabal-install packages, with one of them being the tls option.

I am emphatically against any plan that involves optional dependencies
or distributing two versions of anything. Our users, especially
newcomers, will be confused. Which cabal-install do I need? Which
cabal-install do I have? Why are there two versions? Why doesn't that
version do this? etc. Especially because one version would be used
once and necessarily be discarded, we would need to make the 2-step
installation automatic. That leads us back to a bootstrap script,
which we're already doing. If our current bootstrap facilities are
inadequate, then we need to address that instead.

Distributing two versions also means maintaining two code paths.
Maintaining and testing two *security sensitive* code paths. I would
much rather see us put all our eggs in the http-client basket than
distribute two versions. I say this even as someone who favors the
pipe-out-to-curl option. I have had a bad experience with every HTTP
client library on Hackage (that I know of) and I would take any one of
them over any one of them, plus curl.

-- 
Thomas Tuegel