--build-depends with repl does not consume its list of inputs if it sees allow-newer

[emilypi]

UPD 2023-02-03 Originally, the bug report suggested that the bug is always there, with any project file. It was later discovered by @wismill that the bug only manifests if cabal sees allow-newer -- either in the project file or in the command-line arguments.

Describe the bug
The --build-depends flag does not seem to be respected within a project dir, but oddly works outside of it. I'd expect the following to bring the list of dependencies into scope for the repl for a project, but it does not:

λ П(a: A) base64-bytestring → λ git emily/check-decode-padding → cabal repl --build-depends "vector, sequence, containers, unordered-containers" 
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
...
Ok, five modules loaded.
П> import qualified Data.Map as M

<no location info>: error:
    Could not load module ‘Data.Map’
    It is a member of the hidden package ‘containers-0.6.2.1’.
    Perhaps you need to add ‘containers’ to the build-depends in your .cabal file.

However, if i step outside of the project directory, it works:

λ П(a: A) base-encodings → cabal v2-repl --build-depends "vector, sequence, containers, unordered-containers"
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
 - fake-package-0 (lib) (first run)
Configuring library for fake-package-0..
Preprocessing library for fake-package-0..
Warning: No exposed modules
GHCi, version 8.8.3: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /Users/emilypi/.ghc/ghci.conf
Loaded GHCi configuration from /var/folders/64/kt1f18kn7kzfhjgw25cf1r140000gn/T/cabal-repl.-24971/setcwd.ghci
П> import qualified Data.Map as M
П> 

To Reproduce

Run the above commands.

Expected behavior

I would expect the behavior of --build-depends to be concatenative (modulo conflicts), and work the same inside of a project directory as well as outside.

System information

• OS: MacOS
• GHC: 8.8.3
• Cabal: 3.2

[wismill]

@emilypi do you happen to have allow-newer in your project file?

I encountered this bug too. I found that it does not trigger if I comment allow-newer. In fact, this bug triggers without project file if one uses CLI option --allow-newer.

A reason could be that traverseCondTreeBuildInfo in Distribution.Types.GenericPackageDescription ignores the condTreeConstraints fields of CondTree. The following patch fixes it for me.

--- a/Cabal-syntax/src/Distribution/Types/GenericPackageDescription.hs
+++ b/Cabal-syntax/src/Distribution/Types/GenericPackageDescription.hs
@@ -93,12 +93,18 @@ traverseCondTreeBuildInfo
     :: forall f comp v. (Applicative f, L.HasBuildInfo comp)
     => LensLike' f (CondTree v [Dependency] comp) L.BuildInfo
 traverseCondTreeBuildInfo g = node where
-    mkCondNode :: comp -> [CondBranch v [Dependency] comp] -> CondTree v [Dependency] comp
-    mkCondNode comp branches = CondNode comp (view L.targetBuildDepends comp) branches
+    mkCondNode 
+      :: comp 
+      -> [Dependency] 
+      -> [CondBranch v [Dependency] comp] 
+      -> CondTree v [Dependency] comp
+    mkCondNode comp deps = CondNode comp (view L.targetBuildDepends comp <> deps) 
 
-    node (CondNode comp _ branches) = mkCondNode
-        <$> L.buildInfo g comp
-        <*> traverse branch branches
+    node (CondNode comp deps branches) = mkCondNode
+      <$> L.buildInfo g comp
+      -- [HACK] we cannot operate on dependencies directly
+      <*> fmap (view L.targetBuildDepends) (g (set L.targetBuildDepends deps mempty))
+      <*> traverse branch branches
 
     branch (CondBranch v x y) = CondBranch v
         <$> node x

[ulysses4ever]

@wismill if you solved this, that would be awesome: that was such a showstopper!

[wismill]

Well it is hacky but it is solved in my case (namely run doctest). However I do not know if it works in general. I would prefer a bit more feedback before opening a PR.

[ulysses4ever]

@wismill is you submit a PR, we'll see what ci thinks, which is a good first approximation.

[wismill]

@ulysses4ever PR sent. See my comments on the hacks. Let’s see first if it passes the test suite.

[wismill]

Note that this bug triggers also using --allow-older.