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?

[fgaz]

This change won't make cabal repl / script faster per se, it just means that instead of writing a dummy package on the file system and performing dep resolution etc on it, it should be possible to do that on the fly, without depending on a project. For it to be fast, we'd also need some way to consistently cache those build plans

[Mikolaj]

Noted. Is there a ticket for the caching?

[fgaz]

Not that I know of

[fendor]

I think that cabal env might be an overall smoother experience and easier to implement, considering it basically already works.

A couple of months ago I tried to understand how the fake-package works, it is basically used to just invoke Cabal on it. I don't see a way to continue to use Cabal without the need of a fake-package, as we can't just pass in-memory project metadata to Cabal, afaict.
Personally I do not understand how the suggestion would actually be implemented.

[Mikolaj]

Noted. There go my hopes. :)

[fgaz]

I don't think running Cabal on a package is strictly necessary here. For repl at least, it should be enough to use an in-memory empty project, though maybe this needs a working extra-packages. Nevermind, I didn't know Cabal handled repl too

[gbaz]

I think caching of fake-pkg and etc resulting from cabal repl invocations with basically no other changes could in itself probably eliminate most of the start-up time?

[fendor]

@gbaz well, yes, but I think it would be a good time to remove the fake-package as the script feature would also benefit from that.

Additionally, if cabal repl script.hs works (which I would hope would start to work once the fake-package trick isn't used anymore), then we can even have HLS support for it, which is my personal motivation :)

[bacchanalia]

I've been investigating this and there seem to be two separate issues.

1. Removing the fake-project.cabal files used by global repl and scripts. This requires calling Cabal directly from cabal-install, but it's morally defensible because the build type is always Simple. A minor downside is that since we would no longer store the meta block in the fake-project.cabal file, we'd have to assume that all script changes could effect the meta block. A major upside is we'll be able to use the current directory as the project directory.
2. Don't write cache files during project planning for non-local targets. These are written to a temp dir and never read before being deleted, so it should be straight forward to simply pass a flag to not write them.

If I missed anything please let me know.