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?

[mpickering]

v2-outdated does everything that v1-outdated did.

1. Checks bounds in a v1-freeze-file
2. Checks bounds which come from the project context (cabal.project.freeze, cabal.project, command line etc)
3. Check bounds in local packages

It could also be extended to check bounds for non-local packages, but this seemed like overkill.

Where is it different.

1. Works exactly the same
2. Checks the bounds for the project context, not just a cabal.project.freeze file. Which seems like more correct behaviour to me since a cabal.project.freeze file is no different from a cabal.project file. You might specify your freeze constraints in
3. Uses the project selector to work out which bounds to check and doesn't ignore bounds in flag sections.

If you could try out the patch it would be greatly appreciated @andreasabel. Perhaps I could also quickly add support for build-tool-depends as well if you could guide this collaboration.

[andreasabel]

If you could try out the patch it would be greatly appreciated @andreasabel.

I am happy to try if you put up a (draft) PR.

[mpickering]

Thanks @andreasabel, see #10878