<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 9:22 AM, Patrick Pelletier <span dir="ltr"><<a href="mailto:code@funwithsoftware.org" target="_blank">code@funwithsoftware.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
On 9/14/16 10:39 PM, Michael Snoyman wrote:<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Sep 15, 2016 at 8:25 AM,
Patrick Pelletier <span dir="ltr"><<a href="mailto:code@funwithsoftware.org" target="_blank">code@funwithsoftware.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 9/14/16 9:26 PM, Michael Snoyman wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br>
</span>
AFAIK, this behavior is not clearly documented.<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>I'd be happy to add a comment. Do you have a
recommendation of somewhere to put such an explanation
that would make sense?</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Probably either in:<br>
<br>
<a href="https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command" target="_blank">https://docs.haskellstack.org/<wbr>en/stable/GUIDE/#the-build-<wbr>command</a><br>
<br>
or:<br>
<br>
<a href="https://docs.haskellstack.org/en/stable/build_command/" target="_blank">https://docs.haskellstack.org/<wbr>en/stable/build_command/</a><br>
<br>
or both.<span class="gmail-"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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<br>
</blockquote>
<br>
</span>
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.<span><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Yes, that would at least meet my needs.<span class="gmail-"><br>
<br></span></div></blockquote><div><br></div><div>Cool, both the docs and this new feature are covered in:</div><div><br></div><div><a href="https://github.com/commercialhaskell/stack/pull/2594">https://github.com/commercialhaskell/stack/pull/2594</a> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br>
</blockquote>
<br>
</span>
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.)<br>
<br>
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.<br>
<br>
So, although it's not an apples-to-apples comparison, it
is different behavior than I was getting with my cabal
workflow.<br>
<br>
</blockquote>
<div><br>
</div>
<div>There is the extra-dep field in packages, but it
wouldn't affect this specific case.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
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.<span class="gmail-"><br>
<br></span></div></blockquote><div><br></div><div>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:</div><div><br></div><div>* The common case: list one from Hackage using package/version in the extra-deps field</div><div>* The less common way: specify one from a Git repo or a local directory in the packages field</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> 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.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Thanks! That (along with the tip about --pedantic) is good to know.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br></font></span></div></blockquote><div><br></div><div>FWIW, my common workflow with Stack is the following command:</div><div><br></div><div> stack test --file-watch --fast --pedantic</div><div><br></div><div>Michael </div></div></div></div>