Do not include Paths_* when infering other-modules

[sol]

TL;DR

If you don't want hpack to include Paths_pkg when inferring other-modules, add this to your library/executable/test section:

when:
- condition: false
  other-modules: Paths_pkg

(substitute pkg with your package name)

Thanks @tfausak for providing this workaround!

Problem

The main motivation for adding Paths_* when inferring other-modules is: We want the user to benefit from module inference for other-modules even if she uses Paths_*.

However, adding Paths_* can be problematic in certain situations (see #291 and #251).

Proposed solution

Now that we have generated-other-modules, we could take a different approach, that is: We do not add Paths_* by default when inferring other-modules; a user then can add it to generated-other-modules when needed while still retaining module inference for other-modules.

Disadvantages

1. generated-other-modules maps to Cabal's autogen-modules, which requires cabal-version: 2.0
2. It is a breaking change to package.yaml

To address (1):

When generated-other-modules only contains Paths_* we will not add autogen-modules to the generated .cabal file and instead only add Paths_* to other-modules. I'm not aware of any issues with this approach, as Cabal accepts, but does not require Paths_* in autogen-modules.

To address (2):

To provide an upgrade path we retain the existing behavior and emit a warning when all of the following conditions are true:

1. other-modules is not specified explicitly
2. Any of the Haskell source files contains the substring Paths_*
3. Paths_* is not mentioned explicitly

This is a best effort approach. There is no easy way to make this bulletproof due to CPP and preprocessors. A small number of packages may still break due to this change.

Open question: How to deal with false positives when emitting warnings? Do we need a way to silence the warning?

[quasicomputational]

RE warning suppression: I think we'd need it, and also it should go in package.yaml so that we don't need to teach whatever is driving hpack about it. I don't think it has to be especially fine-grained: just being able to say 'no, I know what I'm doing with my module names, please stop bothering me' is fine.

[sol]

RE warning suppression: I think we'd need it, and also it should go in package.yaml

Yes, I agree that it should go into package.yaml.

[sol]

Apparently, with cabal-version: 2.0 it is required to list Paths_* as autogen-modules:

• Packages using 'cabal-version: 2.0' and the autogenerated module Paths_*
  must include it also on the 'autogen-modules' field besides 'exposed-modules'
  and 'other-modules'. This specifies that the module does not come with the
  package and is generated on setup. Modules built with a custom Setup.hs script
  also go here to ensure that commands like sdist don't fail.

[dbaynard]

Packages using 'cabal-version: 2.0' and the autogenerated module Paths_* must include it also on the 'autogen-modules' field besides 'exposed-modules' and 'other-modules'.

I've just been bitten by this. If hpack generated a Paths_* module it should surely add it to autogen_modules?

[sol]

If hpack generated a Paths_* module it should surely add it to autogen_modules?

Hey, Paths_* is generated by Cabal, but yes, we want to do something here. For now you can try to add it to generated-exposed-modules or generated-other-modules manually as a workaround.

[sol]

@dbaynard alternatively, you can also use verbatim to work around things.

[expipiplus1]

Is it possible to summarize in the documentation what to write to avoid having Paths_.. in the .cabal file for libraries and executables?

For libraries the verbatim block works well, but for executables it seems to remove hpack's ability to automatically search for .hs files and include them in other-modules.

[hyperfekt]

I just hit this with the Haskell Language Server because the package doesn't have a dependency on base but the server is still led to try and evaluate the Paths modules. The resulting behavior is pretty unintuitive.

[tfausak]

I recently ran into this problem in a different context (commercialhaskell/stack#5407). The TL;DR is that we had Paths_pkg in our library, but also (accidentally) had it in our executable and test suite. Newer versions of Stack don't like that. We wanted to remove Paths_pkg from our executables and test suites, but it wasn't clear how to do that (without also losing the automatic module discovery). Fortunately adding this YAML snippet to those components does the trick:

when:
- condition: false
  other-modules: Paths_pkg

I hope that helps other people dealing with this issue. 🌠

[sol]

@tfausak I'm going to add your workaround to the README with #404.

We still want to address the autogen_modules issue in some unobtrusive way (I think it only affects packages that are going to Hackage + require a recent cabal-version).

[rkuprov]

This issue is still alive and well as of 2023.03.10. Shame.

[aryairani]

Are there any numbers on what proportion of packages are using the weird workaround vs depending on the existing behavior?