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

Tue Sep 13 19:26:38 UTC 2016

At this point (and quite sadly) the question is not mainly a technical
one.  We have difficult decisions to make collectively, by our actions,
about whether it's okay to just overlook a years-long campaign of bitter
character assassination aimed at core members of the community.  For this
reason, I think holding some kind of race, and implying that we all ought
to just get behind whoever releases a minor UI tweak first, is more likely
to hurt than help.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160913/3d70f9f9/attachment-0001.html>