On Thu, Apr 30, 2015 at 5:12 AM, Yitzchak Gale <g...@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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
