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

Tue Sep 13 19:13:15 UTC 2016

On 16-09-13 12:07, Theodore Lief Gannon wrote:
> Stack *does* allow direct interaction with GHC:
>
> stack exec -- ghc version
>
I find `stack ghc -- --version` to be a bit easier. Anything after the `--` is
passed as an argument to ghc.

From the help documentation:
stack ghc -- X.hs -o x
> Granted this lacks a bit in brevity, but if you want to issue multiple
> commands from "inside" stack's private environment, you can also just do
> this:
>
> stack exec sh
>
> On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
> > I’ve watched the recent back-and-forth about stack with quite a bit of
> > interest (as many of us have). The discussion inspired me to take another
> > look at stack. Here are the results of that foray.
> >
> > First, a disclosure: While I have appreciated the emergence of a new build
> > tool for Haskell, I have never much liked stack. One of my chief goals in
> > taking another look is to understand better why I do not like it.
> >
> > My task: Set up a Haskell environment on a new machine (a Mac). This
> > machine has no Haskell infrastructure on it.
> >
> > My approach:
> >
> > 1. `brew install haskell-stack`. Success.
> >
> > At this point, I do not have a Haskell project I wish to build. Instead, I
> > really just want the ability to run Haskell expressions in GHCi. So I skip
> > `stack new` and go straight to
> >
> > 2. `stack setup`. This succeeds, but prints out some interesting messages
> > along the way, including
> >
> > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of
> > 71c0a55d0a877954d9590e285c0eb861ace2d8cc
> > > Right Nothing
> >
> > At the end, I am helpfully told
> >
> > > To use this GHC and packages outside of a project, consider using:
> > > stack ghc, stack ghci, stack runghc, or stack exec
> > >
> >
> > So I then
> >
> > 3. `stack ghci`. My computer’s first reaction is to say
> >
> > > Run from outside a project, using implicit global project config
> > > Using resolver: lts-6.17 from implicit global project's config file:
> > /home/rae/.stack/global-project/stack.yaml
> > > Error parsing targets: The specified targets matched no packages.
> > > Perhaps you need to run 'stack init'?
> > > Warning: build failed, but optimistically launching GHCi anyway
> > >
> >
> > which doesn’t make me feel all that comfortable, but then I am indeed
> > delivered to the GHCi prompt, which works as expected.
> >
> > Done with GHCi, I quit. I then want to double-check which version of GHC I
> > got, so I
> >
> > 4. `stack ghc --version`. This command reports
> >
> > > Invalid option `--version’
> >
> > Grumble. It seems I can’t interact with GHC directly.
> >
> > ————
> >
> > At this point, I am reminded why I dislike stack:
> >
> > **It’s optimized for a different workflow than I use.**
> >
> > And I think this fact (repeated by others’ experiences) is why a segment
> > of our community has not celebrated stack as much as other segments have.
> > We all have different workflows.
> >
> > From what I understand about it, stack is great for a project-based
> > workflow. In this workflow, you are working on a Haskell project. You are
> > happy to specify settings in .cabal and stack.yaml files. And you really
> > want your build to work in the future and on other machines.
> >
> > In my experience, stack is not great with a compiler-based workflow. In
> > this workflow, you aren’t quite as organized perhaps and do not have all
> > your settings written. You also want the ability just to compile a file
> > without changing any configurations. You want to be able to start GHCi with
> > a nice set of libraries with which to experiment.
> >
> > I definitely like a compiler-based workflow. I’m sure that many of you
> > prefer a project-based workflow.
> >
> > The great news here is that we have a choice: use stack for a
> > project-based workflow, and don’t use it when you want a compiler-based
> > workflow. No one needs to convince others about personal preferences.
> >
> > But there is one nagging issue: what do we suggest to newcomers? The
> > downloads page right now is not serving us well. (I was legitimately
> > scratching my head at first trying to figure out how to provision a new
> > computer.) Sadly, I don’t see a good option presenting itself. Both
> > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion)
> > serious shortcomings.
> >
> > A. The Haskell Toolchain (that is, what’s currently called the Haskell
> > Platform Minimal) does appear to lack a “here’s what you do first”
> > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to
> > discover — you have to choose the oft-maligned Haskell Platform link before
> > you are told that there is a minimal variant.
> >
> > B. stack sets up GHC in a way that either 1) requires a project-based
> > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary
> > warnings every time GHC is invoked outside of a project. Furthermore, stack
> > prohibits direct interaction with GHC (as in `ghc --version`).
> >
> > There’s more good news here! Both of these problems are really easy to fix.
> >
> > To fix (A), someone just has to write the tutorial.
> >
> > To fix (B), stack just needs a new option so that `stack setup` installs a
> > system GHC. Perhaps it would even be sufficient for `stack setup` to
> > clearly tell the user where ghc is installed and what to add to their PATH.
> >
> > I also think, if readers agree with my conclusions about workflows, we
> > should consider writing up criteria that potential users should consider
> > when choosing what workflow to start with. We’ll need to have a tighter
> > recommendation for those with no experience programming, but most
> > developers should be able to recognize what workflow they prefer and choose
> > accordingly.
> >
> > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then
> > we’ll really be in a quandary about which installation procedure to put
> > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever
> > one happens first gets to be featured first on the page? :)
> >
> > So: Does my characterization of workflows resonate? Have I perhaps
> > identified part of the burning black heart of the reason behind the vitriol
> > of late? Should we fix (A) and (B)?
> >
> > I’m looking forward to hearing your thoughts.
> >
> > Richard
> >
> >
> > -=-=-=-=-=-=-=-=-=-=-
> > Richard A. Eisenberg
> > Asst. Prof. of Computer Science
> > Bryn Mawr College
> > Bryn Mawr, PA, USA
> > cs.brynmawr.edu/~rae
> >
> > _______________________________________________
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160913/12e60599/attachment.sig>