stack doesn't rebuild internal build-tool-depends

[sjakobi]

General summary/comments (optional)

The dhall-lsp-server package has an integration test suite with a registered dependency on an executable of the same package

  build-tool-depends: dhall-lsp-server:dhall-lsp-server

Documentation for build-tool-depends

stack test should ensure that this executable is up-to-date before running the testsuite, but it doesn't.

As a workaround one can specify the executable as a target with stack test my-package:my-exe my-package:testsuite.

Steps to reproduce

$ git clone https://github.com/sjakobi/dhall-haskell
$ cd dhall-haskell
$ git checkout sjakobi/dhall-lsp-server-build-tool-depends
$ stack test dhall-lsp-server:tests
$ echo bla >> dhall-lsp-server/app/Main.hs # Break the executable
$ stack test dhall-lsp-server:tests

Expected

stack test fails while re-building the executable

Actual

stack test doesn't re-build the executable, and runs the test suite with an outdated executable version.

Stack version

$ stack --version
Version 2.3.1, Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878 (8103 commits) x86_64 hpack-0.33.0

Method of installation

stack upgrade

[qrilka]

@sjakobi I get the expected result using the currrent master - https://gist.github.com/qrilka/5d53e6890fd7fba52c33f4ce96dd3d56

[sjakobi]

@qrilka Many thanks for looking into this! :)

Unfortunately there was a bug in the reproduction steps I posted, which I have since corrected. The last step must also be stack test dhall-lsp-server:tests, not just stack test.

stack test causes some reconfiguration, which also triggers a rebuild of the executable.

[qrilka]

Thanks, this way I could reproduce it. The main problem is that Cabal treats library and tool dependencies differently, there are some workarounds for this in Stack but probably not enough in this case. I will look a bit deeper later.

[qrilka]

@sjakobi I finally had another look into this and it looks like the main problem for Stack here is that there is a cross-component dependency in the same package: such dependencies are excluded in the current Stack plans as they lead to cycles. The way out is #4745 but that is an old issue, we still don't have a budget for it. I'd like to implement that issue but unfortunately I don't think I will be able to do it in my spare time. Sorry.

[sjakobi]

Thanks, @qrilka, and no worries! :)

Luckily this issue is fairly simple to work around:

As a workaround one can specify the executable as a target with stack test my-package:my-exe my-package:testsuite.

It can be a pitfall though – if the executable is not rebuilt, one can end up testing an old version of the executable, which can be pretty confusing.