[Haskell-cafe] technical thoughts on stack

[Christopher Allen]

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