[Haskell-cafe] is it normal for docs to be pending for 24 hours?

[Michael Snoyman]

On Sun, Nov 13, 2016 at 4:05 PM, Saurabh Nanda <saurabhnanda at gmail.com>
wrote:

>
>>> * 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)
>>
>
>
> 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.
>
> As I said, I need to read more on this topic.
>
>
>

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:

* A package is a single .cabal file and everything it references
* A project is a set of 1 or more packages, plus some project settings
* Project settings include things like "use this version of GHC," "use
these dependencies," etc.
* 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.


> 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.
>>
>
>
> 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?
>
>
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:

1. It's trivial to mirror them to as many places as desired, and
2. We're leveraging pre-existing infrastructure from others

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.

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.

[1] https://github.com/fpco/stackage#stackage


>
>
>> 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.
>>
>
>
> Where can I read more about GPS Haskell? I managed to get to
> http://www.ozonehouse.com/mark/platform/GPS-Haskell-HIW2014.pdf from your
> blog post at https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes,
> but it's a 404 right now.
>
> -- Saurabh.
>

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:

https://gist.github.com/snoyberg/b53672e04a432ecbedb106d63725b5a4

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161113/91dfeb6c/attachment.html>