<p dir="ltr">The sandboxes vs. non-sandboxed install issues are closely related to the whole issue of not being able to easily update a package once it is installed. Perhaps some effort should be invested in solving that problem instead as it seems to be the core cause for the reinstallations which are so much harder for global packages than for sandboxes. </p>
<div class="gmail_quote">On 22 Mar 2015 18:25, "Gershom B" <<a href="mailto:gershomb@gmail.com">gershomb@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines.<br>
<br>
A) Users that sandbox and users that do not.<br>
B) Libraries that maintain HP compatibility and libraries that do not.<br>
<br>
The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes — platform-installed packages being available in sandboxes and causing trouble.<br>
<br>
However, the current solution we push to new users is lacking in certain ways. In particular, I really don’t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc.<br>
<br>
Furthermore, it is _very_ important to have some community process to “bless” or suggest some set of packages from the zoo of hackage as the “typical” way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc.<br>
<br>
Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes.<br>
<br>
Overall I tend to agree with dons’ comments on the reddit thread (<a href="http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n" target="_blank">http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n</a>) and think the key idea is to preserve _both_ the “one stop installer” aspect of the platform and the “blessed package set” element, but to decouple them from one another.<br>
<br>
This leads to the following proposals:<br>
<br>
1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place.<br>
2) For generic linux point to both ghc and cabal binaries from the core teams.<br>
3) Continue to pick out and list a compatible, “blessed” set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains.<br>
4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes.<br>
<br>
And of these I have one outstanding question — while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can’t solve that, then the MinGHC approach doesn’t yet provide a strictly better solution.<br>
<br>
Cheers,<br>
Gershom<br>
<br>
On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (<a href="mailto:gale@sefer.org">gale@sefer.org</a>) wrote:<br>
> Mark Lentczner wrote:<br>
> > 1) Abandon the Platform…<br>
> ><br>
> > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of<br>
> > "essential" libs + tools. Keeps a consistent build layout and installation<br>
> > mechanism for Haskell.<br>
> ><br>
> > 3) Re-conceive the Platform. Take a very minimal install approach, coupled<br>
> > with close integration with a curated library set that makes it easy to have<br>
> > a rich canonical, stable environment. This was the core idea around my "GPS<br>
> > Haskell" thoughts from last September - but there would be much to work out<br>
> > in this direction.<br>
><br>
> I vote for (3) but in a way that it would *not* be much work.<br>
> We should definitely do the Platform, but with much *less* work.<br>
><br>
> The most important reason we need the Platform is as<br>
> a default selection of quality basic libraries. We should not abandon<br>
> that concept. Curated package sets do not replace that - the<br>
> Platform is not just packages that build together. Nor do OS<br>
> packagers. The platform is a community-wide set of basic default<br>
> packages that are mature, well tested, all work together well,<br>
> and stable.<br>
><br>
> The second most important role of the Platform is a web site<br>
> where you can get a clear picture of how to download and install<br>
> a default Haskell installation for your platform, and a simple view<br>
> of where we are in the parade of releases. That should also continue.<br>
><br>
> The hardest work of the Platform was its role as a way to bootstrap a<br>
> Haskell installation. That is what made it so hard for HP to keep up<br>
> with GHC releases, and what consequently gave people the impression<br>
> that HP is always old. That work doesn't need to be done as part of the<br>
> Platform anymore. We should leverage other good work people are<br>
> doing to create installers, and stop doing it as part of the HP process.<br>
><br>
> The most important part of an HP release should be a cabal package<br>
> that provides the packages in the platform, at the right versions, with<br>
> a specification of the recommended GHC version as a pre-requisite.<br>
><br>
> Perhaps we can also provide an HP-branded slick installer for some<br>
> platforms that does everything in one click, built as a thin wrapper of<br>
> some existing installer. But that should not delay the official release<br>
> of an HP version. It's just a nice-to-have extra.<br>
><br>
> Once we pare down the work needed for an HP release, we should<br>
> release new versions of HP quite often - *more* often than GHC<br>
> releases, not less often.<br>
><br>
> Another thing we should fix is the (now false) impression that HP<br>
> gets in the way of installing other packages and versions due to<br>
> cabal hell. We should make "require-sandbox" the default setting<br>
> in the cabal config file. I would go further - I would add a cabal<br>
> feature to create a sandbox automatically unless "--user" or<br>
> "--global" is specified explicitly. I would make "foo installed" a<br>
> default constraint (that is easy to override) for all platform packages,<br>
> which solves virtually all cabal hell problems (assuming you are<br>
> using a sandbox) and will not keep things old if we release often.<br>
><br>
> Thanks,<br>
> Yitz<br>
> _______________________________________________<br>
> haskell-infrastructure mailing list<br>
> <a href="mailto:haskell-infrastructure@community.galois.com">haskell-infrastructure@community.galois.com</a><br>
> <a href="http://community.galois.com/mailman/listinfo/haskell-infrastructure" target="_blank">http://community.galois.com/mailman/listinfo/haskell-infrastructure</a><br>
><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>