I use cabal new-repl. I actually kind of like having GHC environment files (maybe not as a default) but they remind me of "vim turds" in that they end up littering your projects.
Cheers, Vanessa McHale On 3/28/19 1:09 PM, Iavor Diatchki wrote: > I am quite confused as to how people are using `ghci` without loading > the environment files, at least in the context of cabal v2 (aka "new > cabal"). When you run `ghci` on its own, unless you load an > environment file, you would only have access to globally installed > packages, which is almost never what you want. What is the workflow > that this proposal optimizes? > > The default behavior should be what's commonly useful and, in my > experience, when I run GHCi in the context of a project, I pretty much > always want it to load the environment associated with the project. > It is incredibly useful when you are working on a project where there > are multiple broken modules (e.g., during refactoring), and you want > to fix them one at a time, in the order that makes sense to you. > > -Iavor > > > On Thu, Mar 28, 2019 at 10:02 AM Bardur Arantsson > <[email protected] <mailto:[email protected]>> wrote: > > On 28/03/2019 14.58, Oleg Grenrus wrote: > > There is. Add > > > > write-ghc-environment-files: never > > > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 > or later. > > > > That doesn't really work if you actually want to be able to use both > ways of working, does it? That same thing applies to > > export GHC_ENVIRONMENT=- > > which someone else posted, but at least that can be done by tooling > before invoking ghc. It's odd to have to change a global setting to > avoid this. (However, thanks for the hints -- I'll be setting that > GHC_ENVIRONMENT from now on.) > > +1 for changing the default. > > It seems really weird to force other tooling to opt out when this > could > easily be solved by just having > > cabal ghci > cabal ghc > > commands which set up the environment properly and tell users to use > that if they want to use cabal's environment files. FWIW, I also see > e.g. ghc as low-level tooling akin to the plain 'gcc' command whereas > e.g. cabal or stack are more like cmake + make/ninja, i.e. it's not > something users should really be running unless they know what they're > doing *and* it should be as tooling-friendly as possible. > > Regards, > > _______________________________________________ > ghc-devs mailing list > [email protected] <mailto:[email protected]> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
