Implement v2-outdated command for cabal-install

[mpickering]

This commit updates the outdated command to the new v2 architecture:

• Transform the old outdated command into a new v2-style command v2-outdated
• Support three modes of operation:
  • Check for outdated dependencies in v1-style freeze file
  • Check for outdated dependencies in project context (cabal.project & cabal.project.freeze)
  • Check for outdated dependencies in local packages

Since the cabal outdated command now supports the v2-architecture, you can request to run the v2-outdated command on any target.

I also introduced the resolveTargetsFromLocalPackages which resolves which local packages targets refer to without having to run the solver. This will be useful for cabal check as well.

A change in behaviour from before is that the package description is flattened, so all bounds will be warned about rather than those in conditional branches being ignored.

Fixes #8283

Please read Github PR Conventions and then fill in one of these two templates.

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[andreasabel]

So I did a first try:

hackage-security $ cabal-master outdated                    
Warning: this is a debug build of cabal-install with assertions enabled.
Configuration is affected by the following files:
- cabal.project
Error: [Cabal-7134]
No targets given and there is no package in the current directory. Use the target 'all' for all packages in the project or specify packages or components by name or location. See 'cabal build --help' for more details on target options.

$  cabal-master outdated all                                                                        
Warning: this is a debug build of cabal-install with assertions enabled.
Configuration is affected by the following files:
- cabal.project
Outdated dependencies:
containers >=0.5.11 && <0.8 (latest: 0.8,
hackage-security-0.6.2.6:lib:hackage-security)
Cabal >=2.2.0.1 && <2.6 || >=3.0 && <3.7 (latest: 3.14.1.1,
hackage-security-0.6.2.6:lib:hackage-security)
Cabal-syntax <3.7 (latest: 3.14.1.0,
hackage-security-0.6.2.6:lib:hackage-security)
Cabal >=2.2.0.1 && <2.6 || >=3.0 && <3.7 (latest: 3.14.1.1,
hackage-security-0.6.2.6:test:TestSuite)
Cabal-syntax <3.7 (latest: 3.14.1.0, hackage-security-0.6.2.6:test:TestSuite)
Cabal >=2.2.0.1 && <3.7 (latest: 3.14.1.1,
example-client-0.1.0.0:exe:example-client)
Cabal-syntax <3.7 (latest: 3.14.1.0,
example-client-0.1.0.0:exe:example-client)
Cabal >=2.2.0.1 && <2.6 || >=3.0 && <3.7 (latest: 3.14.1.1,
hackage-repo-tool-0.1.1.4:exe:hackage-repo-tool)
Cabal-syntax <3.7 (latest: 3.14.1.0,
hackage-repo-tool-0.1.1.4:exe:hackage-repo-tool)
containers >=0.5.11 && <0.8 (latest: 0.8,
precompute-fileinfo-0.1.0.0:exe:precompute-fileinfo)

So, great improvement over the status quo already, thanks!

Wishlist:

• cabal outdated defaults to all if no targets are given
• the output is more clearly structured, e.g. a hierarchical bullet list with package names as first level, targets as second level and dependencies as third level level:

Outdated dependencies:
* hackage-security
  - lib:hackage-security
    * containers >=0.5.11 && <0.8 (latest: 0.8)
    * Cabal >=2.2.0.1 && <2.6 || >=3.0 && <3.7 (latest: 3.14.1.1)
  - test:TestSuite
  - ...
* example-client
* ...

[mpickering]

cabal outdated defaults to all if no targets are given

I agree with this, but it's the same how cabal build and all other v2- commands work.

the output is more clearly structured, e.g. a hierarchical bullet list with package names as first level, targets as second level and dependencies as third level level:

Yes, I can implement this, I just ran out of steam for this initial patch.

Thanks for the feedback.

[alexfmpe]

Check for outdated dependencies in project context (cabal.project & cabal.project.freeze)

Nice, I really miss this

A change in behaviour from before is that the package description is flattened, so all bounds will be warned about rather than those in conditional branches being ignored.

Does this apply to all conditionals? Just realised today that (v1) cabal outdated doesn't see through bounds gated behind something like if impl(ghcjs) || arch(javascript): reflex-frp/reflex-dom#497

[mpickering]

Yes, the bounds are collected from all conditional branches.

[geekosaur]

What happens with bounds that can't be satisfied on the machine? (I think this might only be an issue with pkgconfig-depends which I think this can't deal with anyway?)

[mpickering]

@geekosaur The way that outdated works is that it just checks if there a newer version available from hackage, it doesn't even run the solver, so "unsatisfiable" bounds are gathered and warned about.

[mpickering]

@andreasabel The output now looks like:

[nix-shell:~/cabal-scratch]$ /home/matt/cabal-scratch/dist-newstyle/build/x86_64-linux/ghc-9.10.1/cabal-install-3.15.0.0/x/cabal/build/cabal/cabal v2-outdated all
Warning: this is a debug build of cabal-install with assertions enabled.
Configuration is affected by the following files:
- cabal.project
Outdated dependencies:
* Cabal-QuickCheck
  - lib:Cabal-QuickCheck
    * QuickCheck ^>=2.13.2 || ^>=2.14 (latest: 2.15.0.1)
* Cabal-tests
  - test:check-tests
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
  - test:hackage-tests
    * base-compat >=0.11.0 && <0.14 (latest: 0.14.1)
  - test:no-thunks-test
    * nothunks >=0.1.1.0 && <0.3 (latest: 0.3.0.0)
  - test:parser-tests
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
    * base-compat >=0.11.0 && <0.14 (latest: 0.14.1)
  - test:unit-tests
    * QuickCheck >=2.14 && <2.15 (latest: 2.15.0.1)
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
* cabal-benchmarks
  - test:cabal-benchmarks
    * tasty-bench >=0.3.5 && <0.4 (latest: 0.4.1)
* cabal-testsuite
  - lib:cabal-testsuite
    * containers ^>=0.5.0.0 || ^>=0.6.0.1 || ^>=0.7 (latest: 0.8)

What do you think? Perhaps you could approve the PR if it looks good.

[andreasabel]

Thanks, excellent work @mpickering !

Seems like one test output needs update still (CI broken).
I placed some comments on whether the output should be sorted/nubbed...

[mpickering]

I have updated the broken test and responded to your comments @andreasabel

[andreasabel]

I tried cabal outdated all on some project and I am very pleased with the outcome. Great work!

[Mikolaj]

Great job!

[mergify]

This pull request has been removed from the queue for the following reason: checks failed.

The merge conditions cannot be satisfied due to failing checks:

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.