Meta-issue: Remove need for fake-package

[phadej]

The internals of cabal-install should allow project planning without writing things to file system.

This is high-level goal, and I don't think that it could be solved with single PR. But internal changes moving us closer to it will improve state of the codebase, which is very welcome!

[fendor]

Where is this fake-package used?
I know of:

• cabal scrips

[phadej]

@fendor, install, run, repl outside of project directories. About everywhere where we "solve", but don't have a local project.

[phadej]

#6885 is another (upcoming) example, where planning without relying (selectively!) on "real world" / "filesystem" inputs is desired.

[alexbiehl]

We could modify the Rebuild monad. Currently it's the one that creates all the caches and triggers rebuilding in case any input changed. By providing configuration or a different interpreter we could just make it not cache things and rebuild all the time.

Pair that with allowing an empty, implicit project and we might be golden.

[phadej]

@alexbiehl yes, that what I have tried. Yet Rebuild monad is used very little, here and there. One clear subgoal is to make project planning contained completely in Rebuild monad.

[alexbiehl]

One clear subgoal is to make project planning contained completely in Rebuild monad

Yes. Though a less invasive change might be to pass down the configuration/interpreter to the runRebuild calls. They are not too many. Maybe it even makes sense to tie the runRebuild to DistDirLayout; we are passing that around everywhere and usually the call looks like runRebuild distDirProjectRoot $ do ....

[phadej]

... except the very first runRebuild is runRebuild "".

I also don't understand why we work with relative paths at all. That's another yak to shave. #6667 might help.

EDIT: I emphasize, this shouldn't be fixed in a "smallest possible diff" way, but in the "cleanest end result" way.

[typedrat]

This is very interesting. I never liked the whole fake-package chicanery, and I think I still understand how that part of Cabal works pretty well, even if I haven't been up to my arms in it recently.

I had a few thinks about how this could be done, actually. Let me try to find my old notes!

[fgaz]

#6999 is a specific bug caused by fake-package

[Mikolaj]

It seems the slowness caused by writing to the filesystem makes cabal repl unusable to some users (e.g., haskell/cabal-userguide#1 (comment)). Therefore, given that we'd love to get rid of v1-, which they use as a substitute for cabal repl, I'd declare this set of tasks as high priority. Another solution to the slowness is cabal env, but would it not benefit from this change as well?