plan execution fails to build computed dependency

[hvr]

This currently affects the 2.0 and master branch

I've create a reasonably minimal repro-case over at https://github.com/hvr/cabal-bugs/tree/master/issue-4432 (the rm -rf part is probably not necessary for reproducing this) . You can see the problem below; I suspect that this may be a corner case involving a local Cabal library.

$ cabal new-build -j1
Resolving dependencies...
In order, the following will be built (use -v for more details):
 - Cabal-1.25.0.0 (lib) (first run)
 - base-orphans-0.5.4 (lib) (requires build)
 - transformers-compat-0.5.1.4 (lib) (requires build)
 - cabal-doctest-1 (lib) (requires build)
 - tagged-0.8.5 (lib) (requires build)
 - distributive-0.5.2 (lib:distributive) (requires build)
 - bug-0 (lib) (first run)
Configuring library for Cabal-1.25.0.0..
Preprocessing library for Cabal-1.25.0.0..
Building library for Cabal-1.25.0.0..
Configuring library for base-orphans-0.5.4..
Preprocessing library for base-orphans-0.5.4..
Building library for base-orphans-0.5.4..
[1 of 2] Compiling Data.Orphans.Prelude ( src/Data/Orphans/Prelude.hs, dist/build/Data/Orphans/Prelude.o )
[2 of 2] Compiling Data.Orphans     ( src/Data/Orphans.hs, dist/build/Data/Orphans.o )
Installing library in /home/hvr/.cabal/store/ghc-8.0.2/base-orphans-0.5.4-982467a5ac7bbf2cffaf0aa75d70cd89144cf8ad3d49ec14dcbc91afa87fc464/lib
Configuring library for transformers-compat-0.5.1.4..
Preprocessing library for transformers-compat-0.5.1.4..
Building library for transformers-compat-0.5.1.4..
[1 of 2] Compiling Paths_transformers_compat ( dist/build/autogen/Paths_transformers_compat.hs, dist/build/Paths_transformers_compat.o )
[2 of 2] Compiling Control.Monad.Trans.Instances ( src/Control/Monad/Trans/Instances.hs, dist/build/Control/Monad/Trans/Instances.o )
Installing library in /home/hvr/.cabal/store/ghc-8.0.2/transformers-compat-0.5.1.4-8e1d956321b8695a2a214c4cc483605a5e92f9d86a100c8e03261cf4ec11e097/lib
Configuring library for cabal-doctest-1..
Configuring library for tagged-0.8.5..
Preprocessing library for tagged-0.8.5..
Building library for tagged-0.8.5..
[1 of 2] Compiling Data.Tagged      ( src/Data/Tagged.hs, dist/build/Data/Tagged.o )
[2 of 2] Compiling Data.Proxy.TH    ( src/Data/Proxy/TH.hs, dist/build/Data/Proxy/TH.o )
Installing library in /home/hvr/.cabal/store/ghc-8.0.2/tagged-0.8.5-609d13fa0a84ebb0b1b526949ac135749ded6381301a67420b356ef9adb9a5c7/lib
<command line>: cannot satisfy -package-id cabal-doctest-1-inplace
    (use -v for more information)
cabal: Failed to build distributive-0.5.2 (which is required by bug-0). The
failure occurred during the configure step.

And here's the dep-tree (pretty-printed by cabal-plan):

bug-0
 ├─ Cabal-1.25.0.0
 │  ├─ array-0.5.1.1
 │  │  └─ base-4.9.1.0
 │  │     ├─ ghc-prim-0.5.0.0
 │  │     │  └─ rts-1.0
 │  │     ├─ integer-gmp-1.0.0.1
 │  │     │  └─ ghc-prim-0.5.0.0 ┄┄
 │  │     └─ rts-1.0 ┄┄
 │  ├─ base-4.9.1.0 ┄┄
 │  ├─ binary-0.8.3.0
 │  │  ├─ array-0.5.1.1 ┄┄
 │  │  ├─ base-4.9.1.0 ┄┄
 │  │  ├─ bytestring-0.10.8.1
 │  │  │  ├─ base-4.9.1.0 ┄┄
 │  │  │  ├─ deepseq-1.4.2.0
 │  │  │  │  ├─ array-0.5.1.1 ┄┄
 │  │  │  │  └─ base-4.9.1.0 ┄┄
 │  │  │  ├─ ghc-prim-0.5.0.0 ┄┄
 │  │  │  └─ integer-gmp-1.0.0.1 ┄┄
 │  │  └─ containers-0.5.7.1
 │  │     ├─ array-0.5.1.1 ┄┄
 │  │     ├─ base-4.9.1.0 ┄┄
 │  │     ├─ deepseq-1.4.2.0 ┄┄
 │  │     └─ ghc-prim-0.5.0.0 ┄┄
 │  ├─ bytestring-0.10.8.1 ┄┄
 │  ├─ containers-0.5.7.1 ┄┄
 │  ├─ deepseq-1.4.2.0 ┄┄
 │  ├─ directory-1.3.0.0
 │  │  ├─ base-4.9.1.0 ┄┄
 │  │  ├─ filepath-1.4.1.1
 │  │  │  └─ base-4.9.1.0 ┄┄
 │  │  ├─ time-1.6.0.1
 │  │  │  ├─ base-4.9.1.0 ┄┄
 │  │  │  └─ deepseq-1.4.2.0 ┄┄
 │  │  └─ unix-2.7.2.1
 │  │     ├─ base-4.9.1.0 ┄┄
 │  │     ├─ bytestring-0.10.8.1 ┄┄
 │  │     └─ time-1.6.0.1 ┄┄
 │  ├─ filepath-1.4.1.1 ┄┄
 │  ├─ pretty-1.1.3.3
 │  │  ├─ base-4.9.1.0 ┄┄
 │  │  ├─ deepseq-1.4.2.0 ┄┄
 │  │  └─ ghc-prim-0.5.0.0 ┄┄
 │  ├─ process-1.4.3.0
 │  │  ├─ base-4.9.1.0 ┄┄
 │  │  ├─ deepseq-1.4.2.0 ┄┄
 │  │  ├─ directory-1.3.0.0 ┄┄
 │  │  ├─ filepath-1.4.1.1 ┄┄
 │  │  └─ unix-2.7.2.1 ┄┄
 │  ├─ time-1.6.0.1 ┄┄
 │  └─ unix-2.7.2.1 ┄┄
 ├─ base-4.9.1.0 ┄┄
 └─ distributive-0.5.2
    ├─ base-4.9.1.0 ┄┄
    ├─ base-orphans-0.5.4
    │  ├─ base-4.9.1.0 ┄┄
    │  └─ ghc-prim-0.5.0.0 ┄┄
    ├─ tagged-0.8.5
    │  ├─ base-4.9.1.0 ┄┄
    │  ├─ deepseq-1.4.2.0 ┄┄
    │  ├─ template-haskell-2.11.1.0
    │  │  ├─ base-4.9.1.0 ┄┄
    │  │  ├─ ghc-boot-th-8.0.2
    │  │  │  └─ base-4.9.1.0 ┄┄
    │  │  └─ pretty-1.1.3.3 ┄┄
    │  ├─ transformers-0.5.2.0
    │  │  └─ base-4.9.1.0 ┄┄
    │  └─ transformers-compat-0.5.1.4
    │     ├─ base-4.9.1.0 ┄┄
    │     ├─ ghc-prim-0.5.0.0 ┄┄
    │     └─ transformers-0.5.2.0 ┄┄
    ├─ transformers-0.5.2.0 ┄┄
    └─ transformers-compat-0.5.1.4 ┄┄
    [setup]
    ├─ Cabal-1.25.0.0 ┄┄
    ├─ base-4.9.1.0 ┄┄
    └─ cabal-doctest-1
       ├─ Cabal-1.25.0.0 ┄┄
       ├─ base-4.9.1.0 ┄┄
       ├─ directory-1.3.0.0 ┄┄
       └─ filepath-1.4.1.1 ┄┄

[hvr]

Looking a bit closer at the output, I notice that part of the problem is cabal-doctest becoming an inplace package... as it started depending on the local Cabal lib. Is this expected?

And in fact, if I use --constraint 'setup.Cabal < 1.25' I can keep cabal from using the local Cabal package to satisfy bug's (implicit) setup-depends...

@grayjay Is there a generic way to control whether qualified goals pick up local/inplace packages?

[ezyang]

It is "expected", in the sense that if you inplace Cabal or any other package that might get picked up by custom setup depends, it will force the setup script to be built this way. But I think you could reasonably want it to go either way. I thought I've complained about this before but I can't find the ticket. 9aa4b9f and f9139d7 and 3003d06 may be of interest. I haven't looked at the actual bug you reported.

[hvr]

@ezyang I see; well, if either way can be argued for, one just needs a way to let the user control which way to use, and then decide on the default which is most popular...

Btw, --constraint 'setup.Cabal installed' is not what I want. It appears to me we may need a new verb besides installed to denote inplace vs non-inplace (or local vs non-local).

[grayjay]

Here's a previous discussion about the topic: #3706 (comment)

I think we do need a new type of constraint to specify whether cabal should use the local copy of a package. I would rather add a local vs non-local constraint than an inplace vs non-inplace constraint. Local vs non-local seems more simple and direct, because it only determines what source code is used for the package that the constraint applies to.

[hvr]

I agree, local/non-local makes more sense.