Improving the "Get Haskell Experience"

[Greg Weber]

On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru
> wrote:

> Greg Weber <greg at gregweber.info> writes:
> > The main reason I am using stack is for its support for building a
> project
> > containing multiple packages. There aren't any other tools that make
> this a
> > first-class concept that is easy to use and not buggy.
> > In addition, stack has a first-class concept of curated package sets.
> All of these
> > are required to have smooth installs in real world projects, and they
> aren't
> > likely to appear in cabal-install in a short time frame.
>
> The problem that I'm personally facing all too often, is exploratory
> development, where the modus operandi is to try using versions/branches
> that are not yet released on Hackage.
>
> Things like this happen especially during GHC version transitions, where
> ghc-new buildability of libraries/tools is often in flux, and so you
> /have/ to chase the tail (or is it HEAD?).
>
> As an example, the version of ghc-mod that works with 7.10 is still
> unreleased on Cabal -- months passed, the prospects still indefinite.
>
> But it also happens out of plain curiosity and willingness to try out
> how new things could affect the way of problem expression.
>
> For an example of that, let's take the 'nokinds' branch of GHC, where
> Richard Eisenberg does research on formulating GHC with dependent types.
>
> Another situation where these things matter especially is collaborative
> development -- trying to help with bugs, for example.
>
> All these things ring of the same, actually..
>
> ..where Hackage puts a mild barrier to sharing small contributions with
> the world, Stack puts a wall.
>

I think you are using the wrong terminology. You probably mean to compare
"stackage" with "Hackage".
But your replly is supposed to be about "stack", which has first-class
support for building packages that are not on Hackage as part of your
project, including fetching the package from github for you.
https://github.com/commercialhaskell/stack/wiki/stack.yaml#project-config


> Which is a good thing.
>
> But also a bad one.
>
> ..and unless I'm wrong, and we're indeed moving to a world where people
> would
> increasingly use Stack, this dichotomy is /bound/ to become more pressing.
>
> Curiously, there's a technology to solve to both sides of the story -- Nix,
> which was mentioned before, but I think its salient point applies
> especially
> well to this dichotomy:
>
>  1. use the existing curated releases, but also can
>  2. override packages with a Github fork URL, commit id and the physical
>     checkout hash -- and have everything pick it up in a transparent,
> fixpoint way.
>

Again, there is already support for this in stack. Give it a try.


> Admittedly it's not been made as trivial to use -- there's more moving
> parts to factor, and up until now there just wasn't any party seriously
> interested in doing the user-facing parts.
>
> ..And so, I can't help but wonder.. what if the Stack authors would have
> applied their expertise to provide the same user experience they
> achieved..
>
> ..but with Nix as an underlying technology?
>

Then stack would be forcing Windows users to use cygwin


>
> --
> respectfully,
> Косырев Серёга
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150713/3ca78381/attachment.html>