On Sun, Nov 13, 2016 at 3:35 PM, Saurabh Nanda <saurabhnanda@gmail.com> wrote:

Hackage and Stackage serve different purposes. Hackage is all packages, while Stackage is a curated set of packages. (Therefore, Hackage is essentially the "upstream" of Stackage.) We shouldn't give up on Hackage.

I know I'm jumping into a very, very touchy topic, but isn't the following possible:

* Stackage & Hackage combine -- even the .cabal & .stack file formats (if possible)

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:

* That's about Stack vs cabal-install instead of Stackage vs Hackage

* 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)

* The combined entity supports curated packages (via LTS) AND a global free-for-all package list. I, as a user, get to decide how I want my packages to be resolved -- via a curated LTS or via the global package index.

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 stackage.org so that adding the functionality to Hackage wasn't a blocker for getting curated package sets available to users.

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.

* The combined entity focuses on building a kickass, unified, piece of community infra, instead of dividing effort+resources and solving similar problems twice.

It's a wonderful idea.

Michael