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

Christopher Allen

14 Sep 2016 14 Sep '16

3:21 p.m.

What are you talking about? $ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier wrote:

...

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, compiler warnings get squirreled away in a file that I have to go hunting for. It would be nice to have an option to print warnings (for local packages, not dependencies) to stderr.

--Patrick

_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- Chris Allen Currently working on http://haskellbook.com

Show replies by date

Christopher Allen

14 Sep 14 Sep

3:26 p.m.

New subject: [Haskell-community] technical thoughts on stack

Near as I can tell, it _is_ going to stderr just like you'd expect too $ stack build > log_output simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hi"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... simple-library-0.1.0.0: copy/register Installing library in /home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/lib/x86_64-linux-ghc-8.0.1/simple-library-0.1.0.0-IZ2irAKiR4w8tX3NVir98W Installing executable(s) in /home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/bin Registering simple-library-0.1.0.0... [ callen@pardalis ~/work/simple-library master ✗ ] $ stack build 2>&1 > log_output On Wed, Sep 14, 2016 at 2:21 PM, Christopher Allen wrote:

...

What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier wrote:

...
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, compiler warnings get squirreled away in a file that I have to go hunting for. It would be nice to have an option to print warnings (for local packages, not dependencies) to stderr.

--Patrick

_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

-- Chris Allen Currently working on http://haskellbook.com

-- Chris Allen Currently working on http://haskellbook.com

Patrick Pelletier

3:42 p.m.

New subject: [Haskell-community] technical thoughts on stack

On 9/14/16 12:21 PM, Christopher Allen wrote:

...

What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me: whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o ) Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool() Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o ) Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$ I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage. --Patrick

David McBride

3:56 p.m.

New subject: [Haskell-community] technical thoughts on stack

The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info. I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output. On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier

...

wrote:

...

On 9/14/16 12:21 PM, Christopher Allen wrote:

...
What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me:

whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInse nsitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization -insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod e/NormalizationInsensitive/Internal.o )

Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool()

Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant

Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize

Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode

Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize"

Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod e/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Ca bal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o )

Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in /Users/ppelleti/programming/haskell/normalize/.stack-work/in stall/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/ normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$

I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage.

--Patrick

_______________________________________________ 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.

Christopher Allen

4:10 p.m.

New subject: [Haskell-community] technical thoughts on stack

I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings. Example:

...

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning: $ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using: /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’ One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote:

...

The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info.

I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output.

On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier wrote:

...
On 9/14/16 12:21 PM, Christopher Allen wrote:

...
What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me:

whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o )

Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool()

Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant

Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize

Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode

Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize"

Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o )

Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in

/Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$

I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage.

--Patrick

_______________________________________________ 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.

-- Chris Allen Currently working on http://haskellbook.com

Patrick Pelletier

4:20 p.m.

New subject: [Haskell-community] technical thoughts on stack

On 9/14/16 1:10 PM, Christopher Allen wrote:

...

I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library

Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning:

Hmmm... that is what I'm doing. My stack.yaml contains: packages: - normalization-insensitive/ - photos/ - unicode-transforms/ The package I'm developing is normalization-insensitive, but I need unicode-transforms as a dependency. (And at the time, unicode-transforms was not available on hackage, so I had to check it out locally.) And then photos is a simple application that uses normalization-insensitive. But when I do "stack build", it does not print the warnings for normalization-insensitive. --Patrick

Christopher Allen

4:26 p.m.

New subject: [Haskell-community] technical thoughts on stack

Weird. I'd say it's worth raising a bug over whether it's intentional behavior or not. A package not marked as an extra dep IME reports warnings and IMO _should_. If you don't have time, tell me and I'll report it for you. On Wed, Sep 14, 2016 at 3:20 PM, Patrick Pelletier wrote:

...

On 9/14/16 1:10 PM, Christopher Allen wrote:

...
I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library

Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning:

Hmmm... that is what I'm doing. My stack.yaml contains:

packages: - normalization-insensitive/ - photos/ - unicode-transforms/

The package I'm developing is normalization-insensitive, but I need unicode-transforms as a dependency. (And at the time, unicode-transforms was not available on hackage, so I had to check it out locally.) And then photos is a simple application that uses normalization-insensitive.

But when I do "stack build", it does not print the warnings for normalization-insensitive.

--Patrick

-- Chris Allen Currently working on http://haskellbook.com

David McBride

4:26 p.m.

New subject: [Haskell-community] technical thoughts on stack

That's not what I'm observering. I intentially put -Wall and some odd code in a local copy of pipes-csv, stack clean, stack build. /home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: A do-notation statement discarded a result of type ‘String’ Suppress this warning by saying ‘_ <- getLine’ or by using the flag -fno-warn-unused-do-bind In another project, stack clean, stack build pipes-csv-1.4.0: configure pipes-csv-1.4.0: build pipes-csv-1.4.0: copy/register Nothing at all. stack.yaml is basically this, but with a few extra packages. flags: {} packages: - '.' - '../pipes-csv-1.4.0' extra-deps: [] resolver: lts-3.1 stack --version Version 1.1.2 x86_64 hpack-0.14.0 On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen wrote:

...

I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library

Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning:

$ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using: /home/callen/.stack/setup-exe-cache/x86_64-linux/setup- Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log

Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o )

/home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’

One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml

On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote:

...
The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info.

I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output.

On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier wrote:

...
On 9/14/16 12:21 PM, Christopher Allen wrote:

...
What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me:

whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/

NormalizationInsensitive/Internal.o

...
)

Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool()

Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant

Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize

Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode

Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize"

Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/ NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/ NormalizationInsensitive.o )

Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in

/Users/ppelleti/programming/haskell/normalize/.stack-work/ install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10. 3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$

I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage.

--Patrick

_______________________________________________ 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.

-- Chris Allen Currently working on http://haskellbook.com

Christopher Allen

4:30 p.m.

New subject: [Haskell-community] technical thoughts on stack

I think mine showed because of an error, they should be visible regardless for packages not marked extra-dep IMO anyway, so I'm going to file the issue. On Wed, Sep 14, 2016 at 3:26 PM, David McBride wrote:

...

That's not what I'm observering. I intentially put -Wall and some odd code in a local copy of pipes-csv, stack clean, stack build.

/home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: A do-notation statement discarded a result of type ‘String’ Suppress this warning by saying ‘_ <- getLine’ or by using the flag -fno-warn-unused-do-bind

In another project, stack clean, stack build

pipes-csv-1.4.0: configure pipes-csv-1.4.0: build pipes-csv-1.4.0: copy/register

Nothing at all.

stack.yaml is basically this, but with a few extra packages.

flags: {} packages: - '.' - '../pipes-csv-1.4.0' extra-deps: [] resolver: lts-3.1

stack --version Version 1.1.2 x86_64 hpack-0.14.0

On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen wrote:

...
I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library

Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning:

$ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using:

/home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log

Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o )

/home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’

One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml

On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote:

...
The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info.

I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output.

On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier wrote:

...
On 9/14/16 12:21 PM, Christopher Allen wrote:

...
What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me:

whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs,

.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o )

Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool()

Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant

Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize

Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode

Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize"

Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs,

.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs,

.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o )

Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in

/Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$

I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage.

--Patrick

_______________________________________________ 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.

-- Chris Allen Currently working on http://haskellbook.com

-- Chris Allen Currently working on http://haskellbook.com

Emanuel Borsboom

7:45 p.m.

New subject: [Haskell-community] technical thoughts on stack

What you describe sounds a lot like this issue: https://github.com/commercialhaskell/stack/issues/2545 On Wed, Sep 14, 2016 at 1:26 PM David McBride wrote:

...

That's not what I'm observering. I intentially put -Wall and some odd code in a local copy of pipes-csv, stack clean, stack build.

/home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: A do-notation statement discarded a result of type ‘String’ Suppress this warning by saying ‘_ <- getLine’ or by using the flag -fno-warn-unused-do-bind

In another project, stack clean, stack build

pipes-csv-1.4.0: configure pipes-csv-1.4.0: build pipes-csv-1.4.0: copy/register

Nothing at all.

stack.yaml is basically this, but with a few extra packages.

flags: {} packages: - '.' - '../pipes-csv-1.4.0' extra-deps: [] resolver: lts-3.1

stack --version Version 1.1.2 x86_64 hpack-0.14.0

Michael Snoyman

15 Sep 15 Sep

12:26 a.m.

New subject: [Haskell-community] technical thoughts on stack

I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings. The dependency output is still sent to log files instead, keeping the console relatively free of output most people will not care about (general feeling I've seen is if a dependency has warnings, you don't want to see them, much less a list of all modules being compiled). The issue is: what happens if you're building multiple local packages? There are a number of options, all of which seem to get in _someone's_ way: 1. What we do today: send all output to the logs 2. Spit output to the console as it occurs, which will interleave content from multiple builds 3. Save the output to a log file, and then display all of the log files to the user at the end, which would result in looking for a needle in a haystack in many cases When I put together the initial code for running builds, I chose (1), which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to). I tested this in the http-client repo by introducing a warning and running: cabal install ./http-client ./http-client-tls/ --ghc-option -Wall You can see the results at: https://gist.github.com/snoyberg/a50f4fc9505aa32aec835630dd749b77 By contrast, `stack build http-client-tls` spits out all of the warnings to the console as they happen. So my recommendation for people who are warning-sensitive and using Stack: 1. Use the `--pedantic` flag to turn on both `-Wall -Werror`. This is doubly-good: not only will you definitely see the warnings, but you won't accidentally miss them by an interim compile. (This can easily happen if you're using the `--file-watch` flag.) 2. Build one package in your project at a time. If people have ideas for other ways of handling this that I haven't listed, let's start a separate thread to discuss them. On Wed, Sep 14, 2016 at 11:26 PM, David McBride wrote:

...

That's not what I'm observering. I intentially put -Wall and some odd code in a local copy of pipes-csv, stack clean, stack build.

/home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: A do-notation statement discarded a result of type ‘String’ Suppress this warning by saying ‘_ <- getLine’ or by using the flag -fno-warn-unused-do-bind

In another project, stack clean, stack build

pipes-csv-1.4.0: configure pipes-csv-1.4.0: build pipes-csv-1.4.0: copy/register

Nothing at all.

stack.yaml is basically this, but with a few extra packages.

flags: {} packages: - '.' - '../pipes-csv-1.4.0' extra-deps: [] resolver: lts-3.1

stack --version Version 1.1.2 x86_64 hpack-0.14.0

On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen wrote:

...
I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings.

Example:

From the stack.yaml for the package that uses my previous example's library:

packages: - '.' - ../simple-library

Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning:

$ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using: /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simpl e-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log

Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o )

/home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’

One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml

On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote:

...
The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info.

I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output.

On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier wrote:

...
On 9/14/16 12:21 PM, Christopher Allen wrote:

...
What are you talking about?

$ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o )

/home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0...

Weird. That's not how it works for me:

whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod

e/NormalizationInsensitive/Internal.o

...
)

Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool()

Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant

Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize

Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode

Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize"

Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod e/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod e/NormalizationInsensitive.o )

Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in

/Users/ppelleti/programming/haskell/normalize/.stack-work/in stall/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/ normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$

I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage.

--Patrick

_______________________________________________ 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.

-- Chris Allen Currently working on http://haskellbook.com

_______________________________________________ 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.

Patrick Pelletier

1:25 a.m.

New subject: [Haskell-community] technical thoughts on stack

On 9/14/16 9:26 PM, Michael Snoyman wrote:

...

I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings.

AFAIK, this behavior is not clearly documented.

...

3. Save the output to a log file, and then display all of the log files to the user at the end, which would result in looking for a needle in a haystack in many cases

Is there any harm in having an option for this? If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable.

...

When I put together the initial code for running builds, I chose (1), which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to).

I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet). cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on. (The one in the current directory.) As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally. They all go in "packages" in the stack.yaml. So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow. Thanks, --Patrick

Michael Snoyman

1:39 a.m.

New subject: [Haskell-community] technical thoughts on stack

On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier

...

wrote:

...

On 9/14/16 9:26 PM, Michael Snoyman wrote:

...
I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings.

AFAIK, this behavior is not clearly documented.

I'd be happy to add a comment. Do you have a recommendation of somewhere to put such an explanation that would make sense?

...

3. Save the output to a log file, and then display all of the log files to

...
the user at the end, which would result in looking for a needle in a haystack in many cases

Is there any harm in having an option for this? If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable.

Perhaps a simple option to --dump-log-output, which at the end of a build prints all logs from all local packages? That's certainly possible, though I haven't touched that part of the code in quite a while.

...

When I put together the initial code for running builds, I chose (1),

...
which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to).

I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet). cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on. (The one in the current directory.)

As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally. They all go in "packages" in the stack.yaml.

So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow.

There is the extra-dep field in packages, but it wouldn't affect this specific case. But really, the way you tell Stack "the package I'm working on now" is by specifying it as a target on the command line, which _does_ work: `stack build http-client-tls` in my example above does in fact display the output on the console. Thanks for the feedback. Michael

Patrick Pelletier

2:22 a.m.

New subject: [Haskell-community] technical thoughts on stack

On 9/14/16 10:39 PM, Michael Snoyman wrote:

...

On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier mailto:code@funwithsoftware.org> wrote:

On 9/14/16 9:26 PM, Michael Snoyman wrote:

I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings.

AFAIK, this behavior is not clearly documented.

I'd be happy to add a comment. Do you have a recommendation of somewhere to put such an explanation that would make sense?

Probably either in: https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command or: https://docs.haskellstack.org/en/stable/build_command/ or both.

...

3. Save the output to a log file, and then display all of the log files to the user at the end, which would result in looking for a needle in a haystack in many cases

Is there any harm in having an option for this? If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable.

Perhaps a simple option to --dump-log-output, which at the end of a build prints all logs from all local packages? That's certainly possible, though I haven't touched that part of the code in quite a while.

Yes, that would at least meet my needs.

...

When I put together the initial code for running builds, I chose (1), which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to).

I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet). cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on. (The one in the current directory.)

As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally. They all go in "packages" in the stack.yaml.

So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow.

There is the extra-dep field in packages, but it wouldn't affect this specific case.

Right. My understanding is that extra-dep is for packages to fetch from Hackage that are outside the current resolver. (Cabal doesn't really have an equivalent option, since its implicit resolver is "everything in hackage.") On the other hand, "cabal sandbox add-source" is for packages on the local filesystem.

...

But really, the way you tell Stack "the package I'm working on now" is by specifying it as a target on the command line, which _does_ work: `stack build http-client-tls` in my example above does in fact display the output on the console.

Thanks! That (along with the tip about --pedantic) is good to know. --Patrick

Michael Snoyman

2:37 a.m.

New subject: [Haskell-community] technical thoughts on stack

On Thu, Sep 15, 2016 at 9:22 AM, Patrick Pelletier

...

wrote:

...

On 9/14/16 10:39 PM, Michael Snoyman wrote:

On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier < code@funwithsoftware.org> wrote:

...
On 9/14/16 9:26 PM, Michael Snoyman wrote:

...
I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings.

AFAIK, this behavior is not clearly documented.

I'd be happy to add a comment. Do you have a recommendation of somewhere to put such an explanation that would make sense?

Probably either in:

https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command

or:

https://docs.haskellstack.org/en/stable/build_command/

or both.

3. Save the output to a log file, and then display all of the log files to

...
...
the user at the end, which would result in looking for a needle in a haystack in many cases

Is there any harm in having an option for this? If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable.

Perhaps a simple option to --dump-log-output, which at the end of a build prints all logs from all local packages? That's certainly possible, though I haven't touched that part of the code in quite a while.

Yes, that would at least meet my needs.

Cool, both the docs and this new feature are covered in: https://github.com/commercialhaskell/stack/pull/2594

...

When I put together the initial code for running builds, I chose (1),

...
...
which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to).

I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet). cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on. (The one in the current directory.)

As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally. They all go in "packages" in the stack.yaml.

So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow.

There is the extra-dep field in packages, but it wouldn't affect this specific case.

Right. My understanding is that extra-dep is for packages to fetch from Hackage that are outside the current resolver. (Cabal doesn't really have an equivalent option, since its implicit resolver is "everything in hackage.") On the other hand, "cabal sandbox add-source" is for packages on the local filesystem.

extra-dep is the term for any package which isn't in the snapshot and is not one of the packages you're working on. There are two ways to get an extra-dep: * The common case: list one from Hackage using package/version in the extra-deps field * The less common way: specify one from a Git repo or a local directory in the packages field The second option is what I'm referring to here, and you can add a `extra-dep` setting there too to make it clear that, for example, `stack test` should not run the test suites for those packages.

...

But really, the way you tell Stack "the package I'm working on now" is by specifying it as a target on the command line, which _does_ work: `stack build http-client-tls` in my example above does in fact display the output on the console.

Thanks! That (along with the tip about --pedantic) is good to know.

FWIW, my common workflow with Stack is the following command: stack test --file-watch --fast --pedantic Michael

3169

Age (days ago)

3170

Last active (days ago)

List overview

Download

14 comments

5 participants

participants (5)

Christopher Allen
David McBride
Emanuel Borsboom
Michael Snoyman
Patrick Pelletier