<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 13, 2016 at 4:05 PM, Saurabh Nanda <span dir="ltr"><<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_7969090470437466035gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>* Stackage & Hackage combine -- even the .cabal & .stack file formats (if possible)</div></div></div></div></blockquote><div><br></div></span><div>Let's not conflate two things. I assume you're talking about stack.yaml as the .stack file format. This should be a completely separate discussion for multiple reasons:</div><div><br></div><div>* That's about Stack vs cabal-install instead of Stackage vs Hackage</div><div>* It's completely necessary to have package-level vs project-level configuration (even cabal-install has a separate project config format separate from the .cabal format)</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>I didn't realise that. Let me read more about the problems that stack is trying to solve vs those that cabal is trying to solve. To my untrained eye, they're solving very similar problems to exist as two separate projects. Isn't a package a kind of a project? Or vice-versa.</div><div><br></div><div>As I said, I need to read more on this topic.</div><span class="gmail-"><div><br></div><div> </div></span></div></div></div></blockquote><div><br></div><div>This has been discussed a few times on this mailing list and Reddit (I think), but I don't have any links handy. The basic idea is:</div><div><br></div><div>* A package is a single .cabal file and everything it references</div><div>* A project is a set of 1 or more packages, plus some project settings</div><div>* Project settings include things like "use this version of GHC," "use these dependencies," etc.</div><div>* Projects allow us to work on multiple packages at once in a coherent way, without hard-coding things like a specific GHC version into a package configuration.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This was discussed in ernest at ICFP in 2014, and the resulting proposal was GPS Haskell. The idea was that Hackage would add support for curated package sets. Personally, I didn't think this was necessary, and cabal-install should have just learnt logic to get information from <a href="http://stackage.org" target="_blank">stackage.org</a> so that adding the functionality to Hackage wasn't a blocker for getting curated package sets available to users.</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>Was the only reason to suggest the fetching of curated lists from Stackage in interest of faster go-to-market? Wouldn't it require the community to maintain 2 sets of highly-available infra? Also, wondering aloud, is the curation process purely algorithmic or human assisted?</div><span class="gmail-"><div><br></div><div></div></span></div></div></div></blockquote><div><br></div><div>One aspect was "faster go-to-market." But I also think there's no reason why one website needs to be the central location for all things. Some people disagree with me, which is fine. In practice though, Hackage has had issues with adding new features, whereas adding new functionality elsewhere is much simpler. As to "maintain[ing] 2 sets of highly-available infra," ignoring questions of whether we actually have 2 such infras right now: all of the Stackage snapshot configurations are actually stored in Git repositories on Github, so:</div><div><br></div><div>1. It's trivial to mirror them to as many places as desired, and</div><div>2. We're leveraging pre-existing infrastructure from others</div><div><br></div><div>In other words, when I said above "point at Stackage," that's not really too relevant anymore. It would really be "point at relevant Github repos," which is precisely what Stack does.</div><div><br></div><div>You probably will want to read the stackage README[1] and linked locations, it include the relevant repos, maintainer agreement, and curator guides, which explains what pieces of the puzzle are algorithmic and which parts human assisted.</div><div><br></div><div>[1] <a href="https://github.com/fpco/stackage#stackage">https://github.com/fpco/stackage#stackage</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In reality, the curated package set feature never got added to Hackage, cabal-install never added curated package set support, GPS Haskell was abandoned, and Stack and LTS Haskell were created instead.</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>Where can I read more about GPS Haskell? I managed to get to <a href="http://www.ozonehouse.com/mark/platform/GPS-Haskell-HIW2014.pdf" target="_blank">http://www.ozonehouse.com/<wbr>mark/platform/GPS-Haskell-<wbr>HIW2014.pdf</a> from your blog post at <a href="https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes" target="_blank">https://www.fpcomplete.com/<wbr>blog/2014/12/backporting-bug-<wbr>fixes</a>, but it's a 404 right now.</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>-- Saurabh. </div></font></span></div>
</div></div>
</blockquote></div><br></div><div class="gmail_extra">I don't have a copy of the presentation linked from the blog post, but here's the email I sent after ICFP 2014 describing the work items to make GPS Haskell a reality:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://gist.github.com/snoyberg/b53672e04a432ecbedb106d63725b5a4">https://gist.github.com/snoyberg/b53672e04a432ecbedb106d63725b5a4</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Michael</div></div>