Why does stack --resolver xyz build still take the extra-deps in the stack.yaml into account?

[sjakobi]

(This uses the dependency error pretty printing from #2236 for clarity)

$ cd stack
$ git checkout 3103ebe
$ echo "resolver: lts-2.22" > stack-repro.yaml

Compare the dependency errors for the following two invocations:

$ stack build --resolver lts-2.22

While constructing the build plan, the following exceptions were encountered:

In the dependencies for stack-1.1.3:
    ansi-terminal-0.6.2.1 must match >=0.6.2.3 (latest applicable is 0.6.2.3)
    binary-tagged must match >=0.1.1, but the stack configuration has no specified version
                  (latest applicable is 0.1.4.0)
    deepseq-1.3.0.2 must match >=1.4 (latest applicable is 1.4.2.0)
    filelock must match >=0.1.0.1, but the stack configuration has no specified version (latest applicable is 0.1.0.1)
    fsnotify-0.1.0.3 must match >=0.2.1 (latest applicable is 0.2.1)
    gitrev-1.0.0 must match >=1.1 && <1.3 (latest applicable is 1.2.0)
    hpack must match >=0.14.0 && <0.15, but the stack configuration has no specified version
          (latest applicable is 0.14.0)
    microlens must match >=0.3.0.0, but the stack configuration has no specified version (latest applicable is 0.4.4.0)
    monad-unlift must match <0.3, but the stack configuration has no specified version (latest applicable is 0.2.0)
    open-browser must match >=0.2.1, but the stack configuration has no specified version (latest applicable is 0.2.1.0)
    path must match >=0.5.1, but the stack configuration has no specified version (latest applicable is 0.5.7)
    path-io must match >=1.1.0 && <2.0.0, but the stack configuration has no specified version
            (latest applicable is 1.1.0)
    project-template-0.1.4.2 must match >=0.2 (latest applicable is 0.2.0)
    regex-applicative-text must match >=0.1.0.1 && <0.2, but the stack configuration has no specified version
                           (latest applicable is 0.1.0.1)
    tls-1.2.18 must match >=1.3.8 (latest applicable is 1.3.8)

In the dependencies for store-0.1.0.1:
    base-orphans must match >=0.4.5, but the stack configuration has no specified version (latest applicable is 0.5.4)
    fail must match >=4.9.0.0, but the stack configuration has no specified version (latest applicable is 4.9.0.0)
    th-reify-many-0.1.3 must match >=0.1.6 (latest applicable is 0.1.6)
needed due to stack-1.1.3 -> store-0.1.0.1

Recommended action: try adding the following to your extra-deps in "/home/simon/src/stack/stack.yaml":
- base-orphans-0.5.4
- binary-tagged-0.1.4.0
- fail-4.9.0.0
- filelock-0.1.0.1
- hpack-0.14.0
- microlens-0.4.4.0
- monad-unlift-0.2.0
- open-browser-0.2.1.0
- path-0.5.7
- path-io-1.1.0
- regex-applicative-text-0.1.0.1
...

$ stack build --stack-yaml stack-repro.yaml 

While constructing the build plan, the following exceptions were encountered:

In the dependencies for stack-1.1.3:
    ansi-terminal-0.6.2.1 must match >=0.6.2.3 (latest applicable is 0.6.2.3)
    binary-tagged must match >=0.1.1, but the stack configuration has no specified version
                  (latest applicable is 0.1.4.0)
    deepseq-1.3.0.2 must match >=1.4 (latest applicable is 1.4.2.0)
    filelock must match >=0.1.0.1, but the stack configuration has no specified version (latest applicable is 0.1.0.1)
    fsnotify-0.1.0.3 must match >=0.2.1 (latest applicable is 0.2.1)
    gitrev-1.0.0 must match >=1.1 && <1.3 (latest applicable is 1.2.0)
    hpack must match >=0.14.0 && <0.15, but the stack configuration has no specified version
          (latest applicable is 0.14.0)
    microlens must match >=0.3.0.0, but the stack configuration has no specified version (latest applicable is 0.4.4.0)
    monad-unlift must match <0.3, but the stack configuration has no specified version (latest applicable is 0.2.0)
    open-browser must match >=0.2.1, but the stack configuration has no specified version (latest applicable is 0.2.1.0)
    path must match >=0.5.1, but the stack configuration has no specified version (latest applicable is 0.5.7)
    path-io must match >=1.1.0 && <2.0.0, but the stack configuration has no specified version
            (latest applicable is 1.1.0)
    project-template-0.1.4.2 must match >=0.2 (latest applicable is 0.2.0)
    regex-applicative-text must match >=0.1.0.1 && <0.2, but the stack configuration has no specified version
                           (latest applicable is 0.1.0.1)
    store must match -any, but the stack configuration has no specified version (latest applicable is 0.1.0.1)
    tls-1.2.18 must match >=1.3.8 (latest applicable is 1.3.8)

Recommended action: try adding the following to your extra-deps in "/home/simon/src/stack/stack-repro.yaml":
- binary-tagged-0.1.4.0
- filelock-0.1.0.1
- hpack-0.14.0
- microlens-0.4.4.0
- monad-unlift-0.2.0
- open-browser-0.2.1.0
- path-0.5.7
- path-io-1.1.0
- regex-applicative-text-0.1.0.1
- store-0.1.0.1
...

In the first run, the dependency solver took the extra-deps from the stack.yaml – store-0.1.0.1 among others – into account.

In this case, this defeats my intention, which is to try to build the project using exactly the package versions defined in lts-2.22.

While the current behavior could be called consistent, I think it's surprising enough that it should be changed.

[harendra-kumar]

Changing a resolver is likely to make extra-deps inconsistent with it so it makes sense to discard the extra-deps.

But we will need a solution for specifying extra-deps as well on the command line if we have to make the solution complete. One way is to support --solver for the build command as well. That will also help installing any package from hackage. For manual specification we can have something like --package that we use for ghc and runghc commands.

See #1693 for precisely this kind of use case.

[mgsloan]

I think it should still take the extra-deps into account, because it may specify things outside of the snapshot. See, for example, how many of the extra-deps are the same between the different configurations in the stack project.

[mgsloan]

I think we're going to leave this behavior for now, it can be useful. Though, as you observe, it is also error prone.

#2656 may be helpful for cases where this matters.