Speaking as an ops guy who does manage said servers, i can tell you that sandboxing apps to let them run their own dependencies is going to be the future for ops. That said, I see the value of “batteries included” because it’s great for anyone teaching anyone else which happens a lot. Having a consistent set of dependencies is also great for the systems engineers. These guys might be looking at a program’s performance in depth, so a server that may not have OpenGL installed still has a huge benefit in using a particular version of a library. The systems engineers can learn just that version of the code, understand its performance well and then pass on the requirements to the ops guys to install just enough packages and libraries in the sandbox to make the application work. The ops guys are happy because they know how many servers to provision and how the application is expected to scale because the systems engineers know every line of code in action, not just the application. 

So, is there value in minimal installs to facilitate sandboxing? Yup

Is there an equal value in standardizing developers around specific sets of library-versions? Yup

Is the future going to be ops installing Haskell Platform into a sandbox? No idea, but that’ll depend on the advocacy of Haskell Platform as the way for developers to write software, among other things



Kind regards,

Yaakov M Nemoy









On Apr 15, 2014, at 21.52, Johan Holmquist <holmisen@gmail.com> wrote:

I strongly believe we need the HP to be able to compete with Python etc with "batteries included". Having a set of blessed packages with stable APIs makes development easier, so the HP is a very important part of the Haskell eco system IMHO.

Having graphics packages in the platform does make it a bit wierd to install on servers which are typically not equipped with OpenGL etc.

Johan


2014-04-16 4:28 GMT+02:00 Simon Hengel <sol@typeful.net>:
> >and I have a somewhat cunning plan along these lines (related to some
> >other ghc-pkg/cabal improvement work) which might make that rather
> >easier
> >
> >what I want is for ghc itself to come with multiple profiles, with one
> >being the minimum (base + rts + deps), and that could be used as a basis
> >for new envs
>
> With such a feature, it sounds like we can get the best of both worlds:
> * a feature-rich Haskell Platform to support beginners
> * minimal sandboxes for advanced users

The issue with such integrated approaches that affect the whole
toolchain (ghc, cabal, etc.) is that this can seriously harm innovation,
at least if the net result is that it gets harder and harder to write
alternative package managers, etc.

TL;DR: If anything, we should make things *less integrated* (read more
open and hackable).

Let me try to make my point by looking at Haddock.  Let's assume you are
not happy with the current state of Haskell documentation tools.  In
such a situation it can makes perfect sense to give it a fresh start.
But Haddock is so integrated with GHC, Hackage, Cabal,...  that this is
very hard to do.  You can write an alternate documentation tool, but it
may be hard for potential uses to experiment with it.  Currently I think
the only feasible way to get your changes in or experiment with new
ideas is through the current maintainer, and if the current maintainer
thinks your approach is a bad idea or just does not like you or does not
have the time to look at your code you may be in a situation where it's
hard to improve things.  There is a lack of competition and I think it
is not something absurd to assume that this lack of competition results
in a lack of innovation.

> >Where would something like the HP actually make sense?  For stuff that
> >has external dependencies that are not easily  installable with
> >cabal-install (like curses bindings, SSL support, etc.).  We have none
> >of this in the HP.  So I think currently we just have additional costs,
> >but no benefits (+ we harm innovation by arbitrarily "endorsing" random
> >packages).
>
> I understand this point of view, but allow me to offer an opposing one.
> By putting packages with external dependencies into Haskell Platform, we
> often increase the dependencies of Haskell Platform itself.  For example,
> Haskell Platform currently includes Graphics packages; installing Haskell
> Platform on a server entails installing a number of OpenGL libraries that
> are never used.

My point here was that (from my perspective) the cost/benefit ratio of
bundling packages that are easily installable with cabal-install is
negative.

Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe