Stop using Prelude at all in autogenerated Paths_<packageName>.hs modules

[jneira]

• As proposed by @Mikolaj in the last pr which removed a reference to a Prelude definition
• To not break projects using alternative preludes, like policeman
• It would be great to have some regression tests checking compiling Paths_ with completely disabled Prelude works
• Splitted from cabal-install 3.6.2 release plan and post tasks #7671

[phadej]

Completely disabled Prelude is very tricky.

• There is IO, return, FilePath. I suspect that someone might actually make a Prelude without FilePath.
• We rely that Data.Version exists. This forces a dependency on base, alternative prelude lib should re-export it. (Data.Version is quite broken type, with tags...)

Note, we cannot even use PackageImports, to make sure we import things from base, as some alternative prelude could be completely overriding. (like base-noprelude and own Prelude module).

I don't see a better alternative then making Paths_<pkgname>.hs module generation configurable, and introduce configuration options as alternative prelude authors & users request them. I would prefer a forward compatible solution, but I have no idea how to make one.

We kind of rely that base or GHC doesn't change, but they do! The current approach of generating Paths module based on what we know and GHC and base is pragmatic, but we cannot #ifdef all possible alternative preludes.

[phadej]

Another idea, which is also not that nice but also not completely awful, is to ask alternative prelude users to use following idiom:

library paths-mypackage
  default-language: Haskell2010
  build-depends: base
  autogen-modules: Paths_mypackage
  exposed-modules: Paths_mypackage

library 
  build-depends: my-favourite-prelude, paths-mypackage

Here, Paths_mypackage is compiled using base: all is fine.

---

This however won't work today, as Paths_<pgkname> is generated
always, so the main library part will recompile it, instead of using
one in paths-mypackage internal lib. #6452 would solve that.

EDIT: maybe one can make it work today using mixins and renaming the module, but that will break stack, as it doesn't support Backpack (i..e incl mixins) use

[jneira]

Adding some more context: a solution for this might fix #5962 (valuable info about possible solutions and caveats there)
In that issue it is linked #1170 (which aims to use an alternative base package)

[jneira]

Note, we cannot even use PackageImports, to make sure we import things from base, as some alternative prelude could be completely overriding. (like base-noprelude and own Prelude module).

Well maybe it is not the optimal solution but maybe using PackageImports could cover a good enough amount of alternative preludes out there in the meanwhile

[phadej]

Well maybe it is not the optimal solution but maybe using PackageImports could cover a good enough amount of alternative preludes out there in the meanwhile

It won't. if you have a package which depends only on relude and doesn't depend on base, nothing will work. Not just import Control.Exception nor import "base" Control.Exception`".

please remember, that all intermediate solutions in Cabal have to be supported until the end of time (or the next complete Hackage reset, whichever happens earlier), so introducing "temporary" solutions is costly. There isn't temporary things in how Cabal works.

[jneira]

please remember, that all intermediate solutions in Cabal have to be supported until the end of time (or the next complete Hackage reset, whichever happens earlier), so introducing "temporary" solutions is costly. There isn't temporary things in how Cabal works.

right, thanks for the reminder, i usually forget that caveat jumping from recent cabal-install changes

[gbaz]

Hrm. Is it possible to teach cabal's builder to just not use the alternate prelude flags when compiling the paths module in particular, and also to always link it to base? I.e. to special-case the compilation of the paths module, instead of the settings within it?

[phadej]

@gbaz, not really.

• When we use ghc --make (i.e. always), we pass all the dependencies and modules at the same time.
• With single-shot module we'd still to pass all the dependencies and modules at the same time when we would ask GHC to produce the module dependency graph.
  • If we hack into it, knowing that Paths_ shouldn't depend on anything in the unit itself, we might get it working. Care should be taken in linking step.

What I propose in #7761 (comment) is essentially "compiling Paths_ with a separate dependencies list". It's (almost) expressible in .cabal today. I don't see a value of adding magic to build process. It's a way simpler to state that using Paths_ module requires a dependency on base (or compatible package), and if that's not possible there is a way to isolate that module into separate unit (if #6452 is fixed).

EDIT: I don't expect #6452 be hard to implement. It's also easy to test. And would make Cabal do less stuff implicitly. These all sounds as wins for me. OTOH, teaching Cabal one more magic trick sounds like something can go wrong in yet to be seen ways. Explicit is better than implicit.

[gbaz]

Sounds good -- so just fixing the above ticket and documenting explicitly your suggestion in 7761 in the cabal docs sounds like the way to go.

[jneira]

What I propose in #7761 (comment) is essentially "compiling Paths_ with a separate dependencies list". It's (almost) expressible in .cabal today.

Afaiu that was also the suggestion in #1170