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

[Michael Snoyman]

On Thu, Sep 15, 2016 at 9:22 AM, Patrick Pelletier <code at funwithsoftware.org
> wrote:

> On 9/14/16 10:39 PM, Michael Snoyman wrote:
>
> On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier <
> code at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160915/43359c0d/attachment-0001.html>