Stack *does* allow direct interaction with GHC: stack exec -- ghc version
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 <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 > > _______________________________________________ > 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-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
