Skip to content

Implement v2-outdated command for cabal-install #10878

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mpickering
Copy link
Collaborator

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:


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).

@mpickering mpickering marked this pull request as draft March 28, 2025 13:22
@andreasabel
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link

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
Copy link
Collaborator Author

Yes, the bounds are collected from all conditional branches.

@geekosaur
Copy link
Collaborator

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
Copy link
Collaborator Author

@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 mpickering force-pushed the wip/v2-outdated branch 2 times, most recently from aedf3e1 to e7ea8fc Compare May 21, 2025 13:27
@mpickering
Copy link
Collaborator Author

@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.

@mpickering mpickering changed the title Draft:Implement v2-outdated command for cabal-install Implement v2-outdated command for cabal-install May 21, 2025
@mpickering mpickering marked this pull request as ready for review May 21, 2025 13:34
@mpickering mpickering force-pushed the wip/v2-outdated branch 3 times, most recently from fae5089 to 4a663b7 Compare May 21, 2025 15:34
Copy link
Member

@andreasabel andreasabel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

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
@mpickering
Copy link
Collaborator Author

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

Copy link
Member

@andreasabel andreasabel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extend cabal outdated to multi-package
4 participants