Disable / Delay "Warning: modules not listed in *.cabal for '*' component (add to other-modules):" Warning

[blitzcode]

From what I can tell, the other-modules field in a cabal file only matters when packaging for a Hackage upload. Cold this warning instead be emitted during the upload check or could we have a flag to disable this warning? It seems pointless to manually maintain a module list or see this warning on every single build for projects that won't end up on Hackage.

[mgsloan]

You make a reasonable point! After typing up the list of pros / cons, I think we should keep the current behavior:

Points in favor of removing the warnings from build (in favor of sdist / upload):

• Less noisy when you don't intend to ever publish the package

Points against removing the warnings from build:

• The user might use cabal-install to upload the project. I'm not sure, but I think cabal will allow the user to upload a broken library, as described here: Cabal will build and install broken library if other-modules is not complete haskell/cabal#2982
• This way, code repos will be encouraged to have a cabal file that's closer to being ready for upload.
• Other things, like stack ghci, also use the list of modules.

We could add a configuration field to suppress this, but I'm inclined to avoid adding extra knobs for stuff like this. What do others think? Is it worth it? I guess I'm not seeing a flag for filtering this output as all that useful, since it's easy to ignore it. Maybe write a utility that pipes the output of stack through something that filters out these lines, if they bug you?

You might like hpack, which allows either exposed-modules or other-modules to be auto-generated. It isn't integrated with stack, but it'd be cool to add support: sol/hpack#61 #1679

[borsboom]

I think our warning support in general could be improved. Right now these warning messages are ad-hoc without any framework around them. It'd be nice is every warning message could be disabled (analogous to GHC's -fno-warn-* options), which would cover this particular issue as well. It'd also be nice if repeated warnings were automatically suppressed and they could be emitted together for a given package instead of being interspersed with other output. What do you think? If so, opening a separate issue would probably be good.

[mgsloan]

Agreed! Another reason to have a system like this is so that they can be moved to the end of the output. Currently it's easy for them to get lost in the midst of output.

We've also sometimes needed to restructure code to plumb warning / error info to the end of output. It'd be nicer to store away warnings / errors at the location that generates them.

[mgsloan]

It'd make a lot of sense to have a proper system for reporting warnings to the user, it's easy to overlook the missing module warnings as they're jammed in the middle of output.

Since other-modules is also used for the dirtiness check (#1797), we may actually want to make it a noisier issue (perhaps it's a bug?)

It seems that we have a whole spectrum - some folks want to make these into errors #1323