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 <cdsm...@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 <r...@cs.brynmawr.edu > <mailto:r...@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. >
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
