[Haskell-community] [Haskell-cafe] technical thoughts on stack

Wed Sep 14 17:47:54 UTC 2016

While we're griping about stack: it seems to place compiler output from
-ddump-... in mysterious places that are hard to find without Google, and
(worse) it seems to do something with stack test output that even Google
can't discover.

On Sep 14, 2016 11:59 AM, "Michael Snoyman" <michael at snoyman.com> wrote:

> I don't think anyone thinks it's bad to have a --with-ghc option, AFAIK
> the only reason it hasn't been done is lack of desire/time, since it's an
> uncommon workflow. Unlike with cabal, the normal way to specify a different
> GHC is with the `--resolver` setting. AFAIK, this flag could be added.
>
> On Wed, Sep 14, 2016 at 6:54 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> But what if I don't want to fiddle with my PATH?  Why is it so bad for
>> stack to have a --with-ghc option to tell it what GHC to use?
>>
>> On 14 September 2016 at 16:23, Christopher Allen <cma at bitemyapp.com>
>> wrote:
>>
>>> Probably pretty similarly to how we use patched GHCJS at work with Stack.
>>>
>>> -- from the stack.yaml
>>> system-ghc: true
>>> compiler: ghcjs-0.2.0_ghc-7.10.2
>>> resolver: ghcjs-0.2.0_ghc-7.10.2
>>>
>>> -- in the Makefile
>>> ghcjs:
>>>     git clone https://github.com/myorg/ghcjs
>>>     cd ghcjs && stack setup && stack install
>>>     cd ghcjs && stack install cabal-install alex happy
>>>     cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock
>>>
>>> It's just picking GHCJS up from the path, with system-ghc: true, we're
>>> telling it that is kosher.
>>>
>>> We disable system-ghc usage for regular GHC projects, it makes
>>> profiling less convenient than if you use a Stack managed GHC but if
>>> you're doing GHC dev the difference means nothing.
>>>
>>> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow <marlowsd at gmail.com>
>>> wrote:
>>> > How would I use stack with a GHC 8.0.2 release candidate?
>>> >
>>> > On 13 September 2016 at 21:27, Christopher Allen <cma at bitemyapp.com>
>>> wrote:
>>> >>
>>> >> Stack is not your shell, a build script, or a Makefile. It already has
>>> >> path management for the GHC installations it provisions and supports.
>>> >> It is not Stack's job to mutilate your path to support external GHC
>>> >> installations.
>>> >>
>>> >> Make a Makefile or add shortcuts to your bashrc to switch compilers.
>>> >>
>>> >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso <
>>> p.giarrusso at gmail.com>
>>> >> wrote:
>>> >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher
>>> Allen
>>> >> > wrote:
>>> >> >>
>>> >> >> Stack users are moving away from enabling system installed GHCs by
>>> >> >> default because it breaks the ease of enabling profiling for
>>> libraries
>>> >> >> when you're using a Stack-installed GHC.
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> I'm not sure why multiple system-installed GHCs needs to be
>>> supported
>>> >> >> in addition to the GHC support Stack already provides. That's extra
>>> >> >> work for...what? Stack isn't trying to compete with Nix. It's more
>>> >> >> like a blend of rustup and cargo -- or Clojure's Leiningen.
>>> >> >
>>> >> >
>>> >> > To clarify: I'm not proposing stack to install those GHCs, just to
>>> use
>>> >> > them.
>>> >> >
>>> >> > I think the extra work would be limited (calling GHC-X.Y.Z instead
>>> of
>>> >> > GHC)
>>> >> > and has other technical advantages
>>> >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind
>>> you, I'm
>>> >> > willing to contribute the work and not asking anybody—I've just been
>>> >> > busy.
>>> >> >
>>> >> > Right now I have to modify the PATH every time I use GHC 7.8.4
>>> because I
>>> >> > needed to customize the build (I'm on OS X 10.11), but I still want
>>> GHC
>>> >> > 8 by
>>> >> > default.
>>> >> >
>>> >> >>
>>> >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso <
>>> p.gia... at gmail.com>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard
>>> Eisenberg
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Thanks, many, for explaining better ways to interact directly
>>> with
>>> >> >> >> GHC
>>> >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping
>>> >> >> >> someone
>>> >> >> >> like
>>> >> >> >> me from liking the ease of `stack setup` is a little missing PR
>>> (as
>>> >> >> >> in,
>>> >> >> >> public relations). I understand that many people want to keep
>>> GHC
>>> >> >> >> cloistered
>>> >> >> >> away to ease version swapping, but others (like me) want GHC
>>> >> >> >> available
>>> >> >> >> front
>>> >> >> >> and center.
>>> >> >> >>
>>> >> >> >> Other minor points:
>>> >> >> >> `stack env` does not work for me: my version of stack does not
>>> know
>>> >> >> >> how
>>> >> >> >> to
>>> >> >> >> `env`.
>>> >> >> >
>>> >> >> >
>>> >> >> > That's correct—stack env was a feature request.
>>> >> >> >
>>> >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say
>>> >> >> > that's a
>>> >> >> > bug
>>> >> >> > (probably because it's a new install)?
>>> >> >> >
>>> >> >> > I use stack (and have contributed a bit recently), but I agree
>>> >> >> > there's a
>>> >> >> > few
>>> >> >> > things stack could do better for this workflow.
>>> >> >> >
>>> >> >> > And the transition has a rather annoying learning curve—stack
>>> ghci
>>> >> >> > and
>>> >> >> > stack
>>> >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to
>>> >> >> > support a
>>> >> >> > project-based workflow, and it has upsides, but it's a transition
>>> >> >> > pitfall.
>>> >> >> >  Lots of things *are* explained in
>>> >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need
>>> learn a
>>> >> >> > few
>>> >> >> > things from scratch.
>>> >> >> >
>>> >> >> > You want stack exec ghc and stack exec ghci, and arbitrary
>>> options
>>> >> >> > require a
>>> >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec
>>> -- ghc
>>> >> >> > --version`. And I'm afraid the command syntax is mostly frozen by
>>> >> >> > now.
>>> >> >> >
>>> >> >> > To support a compiler-based workflow, there are a few things
>>> >> >> > planned—I
>>> >> >> > opened an issue to collect them, starting from Simon Marlow's
>>> recent
>>> >> >> > email:
>>> >> >> > https://github.com/commercialhaskell/stack/issues/2546
>>> >> >> >
>>> >> >> > BTW, a system-installed GHC already works if you stick to one
>>> (and
>>> >> >> > only
>>> >> >> > build projects that need that). But I'd love to support multiple
>>> >> >> > system-installed GHCs and being able to pick the one you need.
>>> >> >> >
>>> >> >> > As others already explained, giving access to stack-installed
>>> GHCs
>>> >> >> > can
>>> >> >> > be
>>> >> >> > problematic—they're going to work, in part, exactly because you
>>> can't
>>> >> >> > install in their package database.
>>> >> >> >
>>> >> >> > Having stack install system-wide GHCs would IMHO risk opening a
>>> can
>>> >> >> > of
>>> >> >> > worms—having working binaries for all Linux distros requires some
>>> >> >> > work,
>>> >> >> > system installers would be harder and most users would dislike
>>> them.
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > Haskell-Cafe mailing list
>>> >> >> > To (un)subscribe, modify options or view archives go to:
>>> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> >> >> > Only members subscribed via the mailman list are allowed to post.
>>> >> >>
>>> >> >> --
>>> >> >> Chris Allen
>>> >> >> Currently working on http://haskellbook.com
>>> >> >> _______________________________________________
>>> >> >> Haskell-Cafe mailing list
>>> >> >> To (un)subscribe, modify options or view archives go to:
>>> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> >> >> Only members subscribed via the mailman list are allowed to post.
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Chris Allen
>>> >> Currently working on http://haskellbook.com
>>> >> _______________________________________________
>>> >> Haskell-community mailing list
>>> >> Haskell-community at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Chris Allen
>>> Currently working on http://haskellbook.com
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160914/c1987b7b/attachment-0001.html>