Extend `cabal outdated` to multi-package

[andreasabel]

E.g. in the root of this repo:

cabal[master]$ cabal outdated
Error: cabal: No cabal file found.
Please create a package description file <pkgname>.cabal

It would be helpful if cabal outdated could also deal with a cabal.project file (instead of .cabal files only), similar to cabal build etc. It could list the outdated dependencies for all packages mentioned in cabal.project (grouped per package).

[erikd]

From HEAD of the cabal repo I get:

cabal run -- cabal outdated
Error: [Cabal-7654]
No cabal file found.
Please create a package description file <pkgname>.cabal

so this is definitely not working now.

[andreabedini]

Copying here some comments from @hvr:

Here's some ideas for how to improve cabal outdated with the nix-local-build UI in mind:

cabal outdated should support target-selectors like new-build et al:

cabal outdated all would then iterate over all local packages configured in cabal.project and check all components for over-constricted bounds.

And it also makes sense to limit outdated to some components, i.e. if only care about a few components (and e.g. not the testsuite): cabal outdated lib:foo exe:doo would only check the two named components in whichever local package they're located.

Conversely, we have special names to e.g. refer to all testsuites in the target-selector; so you could also say cabal outdated tests to iterate over all test-suite components in your cabal.project.

cabal outdated already supports cabal.project.freeze; however, it would be convenient to have a variant which consults the last computed install-plan (and possibly compute one if it's needs (re)computation); IOW, a variant that combines cabal new-freeze with cabal outdated --new-freeze-file but without generating/overwriting an existing cabal.project.freeze file.

[erikd]

cabal outdated all would then iterate over all local packages configured in cabal.project

Isn't this functionality already available somewhere else for all of the new commands to use?

[andreabedini]

If you just want all the local packages you can take inspiration from here

cabal/cabal-install/src/Distribution/Client/CmdFreeze.hs

Lines 126 to 139 in 9f37325

	freezeAction flags@NixStyleFlags{..} extraArgs globalFlags = do
	unless (null extraArgs) $
	die' verbosity $
	"'freeze' doesn't take any extra arguments: "
	++ unwords extraArgs
	ProjectBaseContext
	{ distDirLayout
	, cabalDirLayout
	, projectConfig
	, localPackages
	, buildSettings
	} <-
	establishProjectBaseContext verbosity cliConfig OtherCommand

If you want to accept a target like Herbert is saying you need to do something like this
https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/CmdListBin.hs#L100C3-L100C26

Note that Distribution.Client.CmdOutdated is an odd-ball. It follows the naming of v2 commands (Cmd*) and it uses ProjectFlags but it looks like it follows the pattern of v1 commands after that.

[mpickering]

I have implemented v2-outdated on this branch - https://github.com/haskell/cabal/tree/wip/v2-outdated

If anyone wishes to try it out that would be good. I will tidy up the tests tomorrow.

# cabal outdated all
Configuration is affected by the following files:
- cabal.project
Outdated dependencies:
template-haskell >=2.3.0 && <2.3.1 (latest: 2.4.0.0, package-a-0.1.0.0:lib:package-a)
template-haskell >=2.3 && <2.4 (latest: 2.4.0.0, package-a-0.1.0.0:lib:package-a)
base >=3.0 && <3.5 (latest: 4.0.0.0, package-b-0.1.0.0:lib:package-b)

This also fixes a bug where dependencies in conditional branches were not taken into account.

It didn't seem worth it to to keep the old v1-outdated codepath.

[ulysses4ever]

It didn't seem worth it to keep the old v1-outdated codepath.

I agree with this in principle, but I'd like to point out that last time a move like that prompted a somewhat intense debate: #9107

[andreasabel]

Is v1-outdated doing something not covered by v2-outdated?