Support equivalent of stack --no-load with cabal repl

[sirlensalot]

... namely, not loading all the modules of the library when kicking off cabal repl.

[emilypi]

So this one is going to be code changes in one file.

Add the option here:

• cabal/cabal-install/src/Distribution/Client/CmdRepl.hs

  Line 127 in 1be581d

  envOptions :: ShowOrParseArgs -> [OptionField EnvFlags]

And then you'll need to map that arg to a particular functionality here:

• cabal/cabal-install/src/Distribution/Client/CmdRepl.hs

  Line 199 in 1be581d

  replAction :: NixStyleFlags (ReplFlags, EnvFlags) -> [String] -> GlobalFlags -> IO ()

It looks like the current replAction loads in the project details by default. Adding --no-load will amount to making sure that if that flag is present, then we don't go through with the project load, only bringing up the ghci instance. Beyond that, a changelog entry and doc updates are all that are required.

[gbaz]

can't you just accomplish this by cabal exec ghci?

[emilypi]

That does seem to work, but only after a build:

λ P pact → λ git master → cabal exec ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Loaded package environment from /Users/emilypi/kadena/pact/dist-newstyle/tmp/environment.-8869/.ghc.environment.x86_64-darwin-8.8.4
Loaded package environment from /Users/emilypi/kadena/pact/dist-newstyle/tmp/environment.-8869/.ghc.environment.x86_64-darwin-8.8.4
Loaded GHCi configuration from /Users/emilypi/.ghc/ghci.conf
П> :r
Ok, no modules loaded.
П> :q
Leaving GHCi.
λ P pact → λ git master → cabal clean
λ P pact → λ git master → cabal exec ghci
Resolving dependencies...
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Loaded package environment from /Users/emilypi/kadena/pact/dist-newstyle/tmp/environment.-8924/.ghc.environment.x86_64-darwin-8.8.4
ghc: can't find a package database at /Users/emilypi/kadena/pact/dist-newstyle/packagedb/ghc-8.8.4

Seems like it requires an env file to be present in order to work at all (also, why does it load twice? That's odd output). I think folding this into cabal repl to make sure that edge case is covered would be good UX.

[fendor]

I believe such a flag requires a bit more changes than just in CmdRepl, since the repl action is something that Cabal performs. Thus, Cabal decides which modules are loaded. If we execute cabal repl -v2 in a project, we can see:

> cabal repl -v2
...
act-as-setup --build-type=Simple -- repl --verbose=2
...

which specifies no targets (due to how configure works), but then eventually:

/home/hugin/.ghcup/bin/ghc --interactive -fbuilding-cabal-package <all-these-includes> <package-flags> -XHaskell2010 <list-of-modules>

What we would care about is the list of modules, afaict, and these are added by Cabal.

[fgaz]

can't you just accomplish this by cabal exec ghci?

or --write-ghc-environment-files=always + normal ghci. using plain ghc/ghci is basically what that option is for

[emilypi]

Two questions about that approach @fgaz:

• Can you set project targets at will (say, jumping between test suites and a library) using the environment files approach?
• That setting is off by default for a good reason - it conflicts with nix setups and other flavors of reproduceability, so we probably shouldn't be suggesting people mess around with them as a default. If we can, we should ask cabal-install to just... not load targets if requested. Has the wisdom from the past 4 years changed on the subject of env files? (nix-build haskell callPackage results in ghc: can't find a package database at NixOS/nixpkgs#62906, .gitignore: ignore .ghc.environment.* files i-am-tom/dagmore#1, https://www.reddit.com/r/haskell/comments/9a6fg4/package_environment_files_run_counter_to/, Prevent .ghc.environment flags from getting picked up when running a @repl target. tweag/rules_haskell#516)

[gbaz]

There's a confusion here -- the always flag isn't setting it by default its just setting it for that project. And you can always delete the file. Its a good and useful feature, as long as you're aware you're using it (i.e. by explicitly asking for it). That was the wisdom of the past four years. They're a key, important feature. Just don't hide the fact they're in use.

Environment files don't interact with project targets. They just bring deps into scope (through providing a virtual packagedb, in essence). If the test suite has a bigger dep footprint than the lib, then building with tests enabled will create an environment with dependencies in scope to let you load the test suite, the lib, etc.

Again there's two solutions presented here that seem just fine for the requested functionality -- either cabal exec (which uses an env file under the hood, iirc) or writing an env file explicitly. Both seem very lightweight. In such a case, I'd advocate we don't add more flags and complexity to the cabal executable itself...

[enobayram]

I also need the ability to load a subset of my package's modules in cabal repl without loading the entire package first, but I can't follow the environment files discussion above. I know that having a --no-load flag that simply omits the list-of-modules would solve my issue, and I've already tried cabal exec ghci, but the latter is missing all the modules normally generated during a build.

[gbaz]

@enobayram what do you mean "missing all the modules normally generated"? I don't understand your comment fully.

[enobayram]

@gbaz To be specific, I've tried running cabal exec ghci -- -imy-src-folder which drops me into a ghci session where I can :load modules from my package, but I'll get errors if I need any of the modules like My_package_Paths or those generated by, say happy from .y parser definitions. cabal repl seems to handle such generated modules fine.

BTW, I've tried running cabal repl -v, noted the ghc -interactive call made by it and manually removed all the module names from the arguments list. That drops me into the perfect ghci session where nothing is loaded by default, but I can load any module from my package, so it'd make my life so much easier to be able to run:

cabal repl --no-load --repl-options "-ghci-script some-script-that-loads-a-module-and-then-runs-some-ghci-commands.ghci"

Because as long as cabal repl (without --no-load) adds those modules, whatever I do with my -ghci-script gets clobbered when ghci starts loading those modules afterwards (not to mention the time it takes to load them).

[gbaz]

Ok, this convinced me that in the case of code whose generation is triggered by the cabal build process, we really do want the --no-load flag :-)

[enobayram]

Awesome! I'll readily accept that I don't know enough about the full feature set of cabal to rule out alternative ways to get what I want, but I do know that --no-load would enable very interesting workflows for me.