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

2016-09-27 Thread Phil Ruffwind
On Tue, Sep 13, 2016, at 16:24, Sven Panne wrote: > >* On Windows under a MinGW bash you get a a warning for ghci: > > $ stack --resolver=nightly-2016-07-01 exec ghci -- --version > Run from outside a project, using implicit global project config > WARNING: GHCi

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

2016-09-15 Thread Edward Z. Yang
Excerpts from Harendra Kumar's message of 2016-09-15 13:02:50 +0530: > While I agree that stack.yaml is a frozen config, we do not necessarily > need a separate config file or a separate format for that. My main point > was a that a new user will have to understand two more languages >

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

2016-09-14 Thread Patrick Pelletier
On 9/14/16 10:47 AM, David Feuer wrote: While we're griping about stack: it seems to place compiler output from -ddump-... in mysterious places that are hard to find without Google, and (worse) it seems to do something with stack test output that even Google can't discover. Also,

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

2016-09-13 Thread Patrick Pelletier
On 9/13/16 1:16 PM, Paolo Giarrusso wrote: To clarify: I'm not proposing stack to install those GHCs, just to use them. I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind

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

2016-09-13 Thread Harendra Kumar
There are multiple ways to achieve this: 1) The env command being discussed is actually "stack exec env". Though it includes the full environment rather than stack exclusive. You can use "stack path" to print the stack exclusive environment. You can also use "stack path --" to pick specific items

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

2016-09-13 Thread Christopher Allen
Stack is not your shell, a build script, or a Makefile. It already has path management for the GHC installations it provisions and supports. It is not Stack's job to mutilate your path to support external GHC installations. Make a Makefile or add shortcuts to your bashrc to switch compilers. On

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

2016-09-13 Thread Theodore Lief Gannon
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

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

2016-09-13 Thread Brandon Allbery
On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley wrote: > Some other tools provide an "env" sub-command, so that a person can run: > > eval $(stack env) > > And now ghc, ghci, etc., would be on the PATH, and the user doesn't really > need to care about where it lives. >

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

2016-09-13 Thread Brandon Allbery
On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg wrote: > Other minor points: > `stack env` does not work for me: my version of stack does not know how to > `env` > I think they said that was an add-in. IIRC stack is extensible with external commands, in roughly the same

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

2016-09-13 Thread Brandon Allbery
On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy wrote: > 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

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

2016-09-13 Thread Christopher Allen
Stack users are moving away from enabling system installed GHCs by default because it breaks the ease of enabling profiling for libraries when you're using a Stack-installed GHC. I'm not sure why multiple system-installed GHCs needs to be supported in addition to the GHC support Stack already