new-build doesn't warn when dependencies are out of date

[RyanGlScott]

With old-style cabal, I get nice warnings whenever I try to march ahead with a build plan that uses out-of-date dependencies:

distributive-0.5.2$ cabal install --enable-tests --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
ansi-terminal-0.6.3.1
base-compat-0.9.3
base-orphans-0.6
cabal-doctest-1.0.2
call-stack-0.1.0
code-page-0.1.3
generic-deriving-1.11.2
ghc-paths-0.1.0.9
hspec-discover-2.4.4
primitive-0.6.2.0
random-1.1
setenv-0.1.1.3
stm-2.4.4.1
syb-0.7
transformers-compat-0.5.1.4
HUnit-1.6.0.0
tf-random-0.5
async-2.1.1.1
doctest-0.11.4 (latest: 0.12.0)
tagged-0.8.5
hspec-expectations-0.8.2
QuickCheck-2.10.0.1
quickcheck-io-0.2.0
hspec-core-2.4.4
hspec-2.4.4
distributive-0.5.2

But with new-style cabal, I do not:

distributive-0.5.2$ cabal new-test --dry-run
Resolving dependencies...
In order, the following would be built (use -v for more details):
 - ansi-terminal-0.6.3.1 (lib:ansi-terminal) (requires build)
 - base-compat-0.9.3 (lib) (requires build)
 - base-orphans-0.6 (lib) (requires build)
 - cabal-doctest-1.0.2 (lib) (requires build)
 - call-stack-0.1.0 (lib) (requires build)
 - generic-deriving-1.11.2 (lib) (requires build)
 - ghc-paths-0.1.0.9 (lib:ghc-paths) (requires build)
 - hsc2hs-0.68.2 (exe:hsc2hs) (requires build)
 - hspec-discover-2.4.4 (lib) (requires build)
 - primitive-0.6.2.0 (lib) (requires build)
 - random-1.1 (lib) (requires build)
 - setenv-0.1.1.3 (lib) (requires build)
 - stm-2.4.4.1 (lib) (requires build)
 - syb-0.7 (lib) (requires build)
 - transformers-compat-0.5.1.4 (lib) (requires build)
 - HUnit-1.6.0.0 (lib) (requires build)
 - code-page-0.1.3 (lib) (requires build)
 - tf-random-0.5 (lib) (requires build)
 - async-2.1.1.1 (lib) (requires build)
 - tagged-0.8.5 (lib) (requires build)
 - hspec-expectations-0.8.2 (lib) (requires build)
 - doctest-0.11.4 (lib) (requires build)
 - QuickCheck-2.10.0.1 (lib) (requires build)
 - quickcheck-io-0.2.0 (lib) (requires build)
 - hspec-core-2.4.4 (lib) (requires build)
 - hspec-2.4.4 (lib) (requires build)
 - distributive-0.5.2 (first run)

This makes me quite reluctant to switch over to new-style cabal for daily use, since I rely on cabal to inform me when my version bounds are too constrained.

[hvr]

There's the new cabal outdated command for that, which avoids cluttering new-build's output.

See http://cabal.readthedocs.io/en/latest/developing-packages.html#listing-outdated-dependency-version-bounds

[RyanGlScott]

Ah, nice!

$ cabal outdated
Outdated dependencies:
doctest >=0.11.1 && <0.12 (latest: 0.12.0)
$ echo $?
1

It even reports a non-zero exit code when dependencies are out of date, so I can integrate this into CI tests. Thanks!

[23Skidoo]

Well, these two are not exactly the same. outdated looks at the package description, the cabal install warning looks at the install plan. So you can have a situation when outdated says that everything is OK, but end up with an old dep in the install plan.

[RyanGlScott]

That's a good point. I suppose I have another use case for this - ensuring that other folks' libraries (on which I depend) also have up-to-date dependencies. AFAICT, there's no simple way to check this with new-build other than careful use of --constraint, right?

[23Skidoo]

AFAICT, there's no simple way to check this with new-build other than careful use of --constraint, right?

Right.

outdated looks at the package description

And also the freeze file (both old- and new-style-). I need to think how to best make it new-build-aware, then it can also check your install plan. Restoring the warning should be much easier, though.

[hvr]

@23Skidoo well, doesn't 'cabal new-build' only list the things that aren't cached already? So imho, restoring the old warning isn't that useful. Whereas augmenting cabal outdated to be able to look at the install-plan directly w/o having to go via cabal new-freeze first sounds useful.

[RyanGlScott]

@hvr, I would also be happy with moving this logic to cabal outdated. I think the nub of the issue is that I use cabal install for two different purposes: one for installing packages, and another for leveraging --dry-run to determine what packages are out of date. The second purpose doesn't appear to have a direct counterpart in new-style cabal-install yet, so if cabal outdated feels like the right place for it, then that's fine by me.

[23Skidoo]

well, doesn't 'cabal new-build' only list the things that aren't cached already? So imho, restoring the old warning isn't that useful.

That's a good point. I guess we could make --dry-run print cached stuff as well.

[hvr]

@23Skidoo otoh, having --dry-run to print cached stuff by default would add lots of noise for large projects. I actually like the symmetry that it matches the output you'd get w/o --dry-run, so I'd prefer it if including cached stuff was hidden behind an additional flag, e.g. --dry-run --print-cached. This way you could also have that output enabled w/o --dry-run.

But I still think that cabal outdated --plan is the better & more unified place to have this kind of information, especially since you have the exit-code logic already there for those who want to include this as a CI-check, as well as the ability to mask/ignore some packages (e.g. base) if they're outdated from being considered a CI failure.