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