Generated Paths_ module conflicts with classy-prelude

[23Skidoo]

I have the following common stanza:

common classy-prelude
  build-depends:       base >=4.11 && <4.13
                     , classy-prelude
  mixins:              base hiding (Prelude)
                     , classy-prelude (ClassyPrelude as Prelude)

Unfortunately, the autogenerated Paths_ module conflicts with classy-prelude because they both define catchIO:

    Ambiguous occurrence ‘catchIO’
    It could refer to either ‘Prelude.catchIO’,
                             imported from ‘Prelude’ at .../autogen/Paths_[...].hs:13:1-14
                             (and originally defined in ‘unliftio-0.2.9.0:UnliftIO.Exception’)
                          or ‘Paths_[...].catchIO’,
                             defined at .../autogen/Paths_[...].hs:26:1

[hvr]

I wouldn't call this a bug. The Paths_* module can't operate completely agnostic to build-depends; it has a couple of basic requirements as to the environment it's compiled in. So I'd rather consider this a documentation issue than a bug.

[23Skidoo]

We can easily fix it with an explicit import list. But yeah, it's more of an enhancement than a bug.

[phadej]

We can, but we need still to document most assumptions

• A different prelude can redefine type IO a = HasCallStack => GHC.IO a...
• or makes getEnv take Text or ByteString, and return not String too.
• make FilePath /= String

And these aren't even too far fetched changes.

[23Skidoo]

True.

[23Skidoo]

Related: #1170.

[sloane-shark]

Is there a good workaround for this? I'm using RIO as a prelude replacement and running into the same issue. The only obvious way I can see to fix for myself as of now is to import RIO hiding (catchIO)

[rossabaker]

#1170 looks like a harder problem, but given the assumption of a standard base, I think it's worthwhile progress if we can insulate ourselves from alternate preludes. This compiles for me, and I'd be happy to PR it if there's interest:

{-# LANGUAGE NoImplicitPrelude #-}

-- ...

import qualified Control.Exception as Exception
import Control.Monad (return)
import Data.List ((++))
import Data.Version (Version(..))
import System.Environment (getEnv)
import System.IO as IO

[hvr]

@rossabaker except it doesn't actually shield you from alternative preludes at all... this only helps if the remaining referenced modules in scope still conform to some implicit undocumented assumption. Also, we'd still need to version guard any such changes on cabal-version to reduce the risk of incorrect package metadata (which wouldn't be fixable via Hackage revisions currently) if a newer cabal-version suddenly "just worked" while older versions would still fail to build a package.

Here's a different idea I've been toying with to address this problem in a more principled way: define a new package (say cabal-paths-prelude) with a single module such as Cabal.Paths.Prelude that's unlikely to clash with the namespace of ordinary packages and provides everything that cabal's generated Paths_ module needs; (we'd also avoid NoImplicitPrelude as that's a language extension you can't take for granted).

The cabal-paths-prelude package would effectively define the API that Paths_*.hs needs;
And then, if you want to autogen-modules: Paths_foo, you'd simply have to build-depends: cabal-paths-prelude ^>= 0.1.0.0 or provide the Cabal.Paths.Prelude module conforming to the respective API version yourself by some other means (you could also just have it provided locally in your packages in your other-modules:).

[adamConnerSax]

I know this is an old issue, but when migrating from Cabal-3.4 to Cabal-3.6 and using relude:

 mixins:  base hiding (Prelude)
         , relude (Relude as Prelude
         , Relude.Extra)

which then generates an error when compiling the paths module because relude defines head to operate on NonEmpty rather than []:

XXX/dist-newstyle/build/x86_64-osx/ghc-8.10.7/knit-haskell-0.10.1.0/build/autogen/Paths_knit_haskell.hs:66:22: error:
    • 'last' works with 'NonEmpty', not ordinary lists.
      Possible fix:
          Replace: [Char]
          With:    NonEmpty Char
      
      However, you can use 'last' with the ordinary lists.
      Apply 'viaNonEmpty' function from relude:
          viaNonEmpty last (yourList)
      Note, that this will return 'Maybe Char'
      therefore it is a safe function unlike 'last' from the standard Prelude
    • In the first argument of ‘isPathSeparator’, namely ‘(last dir)’
      In the expression: isPathSeparator (last dir)
      In a stmt of a pattern guard for
                     an equation for ‘joinFileName’:
        isPathSeparator (last dir)
   |
66 |   | isPathSeparator (last dir) = dir ++ fname
   |                      ^^^^^^^^

Going back to 3.4 resolves this.

Can someone explain how to work around this in more detail? Like what is meant by "We can easily fix it with an explicit import list"? Where would the explicit import list go?

I can just go back to cabal 3.4 for now but that doesn't seem like a long-term solution.

[fishtreesugar]

@adamConnerSax I think your issue already fixed in #7650, and cabal-install 3.6.2 will release in recent days #7671

[jneira]

The concrete issue was fixed by #7650 and we have #7761 to rack a more robust solution so i am gonna close this if you dont mind