Cabal: Detect unused packages with new-build

[vmchale]

I would like cabal to support detection of redundant packages with cabal new-build, like weeder or packunused. This would entail:

• [ ] Detecting redundant packages in the .cabal file
• [ ] Making a command-line flag to toggle detection of redundant packages
• [ ] Making a field in cabal.project files to toggle detection of redundant packages
• [ ] Print out warnings/errors and set exit code when redundant packages are found

I can do all of the work, but I would like to know that this is a welcome feature before getting started.

[angerman]

I for one would like to see this. Even though I like the Unix approach of one tool for one task, having this in cabal without the need for a secondary tool would get a lot more usage than what wieder or packunused get today.

I would also argue we have precedence for this in cabal already with the missing module listing warnings.

[gbaz]

prior ticket on this: https://github.com/haskell/cabal/issues/1820

i'd be all for this.

[hvr]

Fwiw, it was always the plan for me to eventually integrate packunused into cabal, but this is missing an important feature from GHC that didn't make it for GHC 8.4 unfortunately (i.e. having GHC dump the module import dependency graph in a useful way; we already had a diff for that on phabricator -- it's a trivial patch); as the approach packunused is using is fragile/broken/hacky, and so is not suitable for integrating into cabal.

[Yuras]

I think we can teach GHC to warn about unused dependencies. It already has everything on hands to do the check.

GHC loads modules lazyly, so at the end of compilation it has a list of actually used packages, see eps_PIT in ExternalPackageState. We can compare it with the list of --package-ids passed by cabal. Seems to be a simple patch, almost a no-brainer. @hvr, do you think it will work?

[hvr]

@Yuras I'd like to have such a warning in GHC but I don't think this is future-proof if I understand your suggestion correctly as it relies on using ghc --make, i.e. letting GHC be in charge of compiling the whole component-unit. However, we have this long-standing plan to move away from ghc --make towards having cabal orchestrate compilations with single module granularity to allow for more control for better parallelism utilization and other potential benefits (that's one of the other motivations for the phabricator diff).

That being said, if it's a simple patch, I'd strongly suggest to implement it and try it; it may serve as a very useful short-term stopgap solution which I'd love to use if it works.

[Yuras]

@hvr I made a patch, see https://ghc.haskell.org/trac/ghc/ticket/15838

[Yuras]

@hvr The approach I described doesn't work for indirect dependencies. Simply because they are actually required for compilation. E.g. if we specify text and bytestring in build-depends, but import only modules from text, then bytestring will not be reported as unused because text depends on bytestring. Knowing that, I still find the approach useful, though other people may find it not worthy.