How can I designate "internal" modules in my cabal package

Question

I'm using cabal to help organize my dependencies, build process, and testing for a small Haskell project I'm working on. The current cabal file contains lines such as the following:

library
  hs-source-dirs:      src
  exposed-modules:     Project.Exposed1
                       , Project.Exposed2
                         -- pretty please don't use below modules
                       , TestingUtilityFunctions
                       , GenericUtilityFunctions

  other-modules:       Convenient submodule for responsibility separation
                       , Another one

executable E1
  -- relies on Project for both Project.Exposed1 AND GenericUtilityFunctions

testsuite T2
  -- relies on Project for both Project.Exposed2 AND TestingUtilityFunctions

I need to keep TestingUtilityFunctions and GenericUtilityFunctions exposed because they appear in E1 and T2. However, they shouldn't be present in the library since the library's functionality is not to provide generic utility functions (which I change as I see fit), but to provide the interface exposed by Project.Exposed* modules.

Is there any way to make a "private" library (or several, to minimize dependency over-inclusion) which I can use inside my package but across executables and testsuites?

Answer 1

One approach, used in containers, is to use CPP to expose some bindings conditionally, depending on whether or not a test build is being run.

The correct approach, in most cases, is to expose your internals module, with a name like Blah.Blah.Internal, which lets your users play games behind your back while solemnly (but implicitly) warning them that they'd better be careful and that they can't rely on anything in there staying the same from version to version.