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

Tue Sep 13 19:47:14 UTC 2016

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`. I have version 1.1.2, as installed by `brew install haskell-stack`. Regardless, there are a variety of ways of establishing the right PATH.

There was not, to my knowledge, any prior stack gubbins around. This is a new computer I’m working on, and I’m pretty sure this was my first attempt.

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae

> On Sep 13, 2016, at 3:26 PM, Chris Smith <cdsmith at gmail.com> wrote:
> 
> 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 <mailto: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 <http://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 <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/912fe8ea/attachment-0001.html>