I just realised we're missing an ingredient in order to support persistent package-environment workflows for standalone scripts:

Consider the following use-cases:

---

Script requires package environemnts disabled

#!/usr/bin/env runghc
{-# OPTIONS_GHC -package-env=- #-}

main = putStrLn "Hello World"

---

User manually maintains a package environment for scripts or teaching exercises (this is a quite common way to teach Haskell which I subscribe to, by letting students interact with ghc and ghci directly instead, and only properly introducing cabal lateron when it's actually needed)

cabal v2-install --lib lens lens-aeson --package-env=lets-lens

and the scripts shall be using that custom named package environment:

#!/usr/bin/env runghc

{-# OPTIONS_GHC -package-env=lets-lens #-}

import Control.Lens

main = do
   putStrLn "Hello Lens"
   -- ...lens using code...

---

Currently both of these use-cases don't work because

$ ghci-8.6.3 Main.hs 
GHCi, version 8.6.3: http://www.haskell.org/ghc/  :? for help

Main.hs:3:16: error:
    unknown flag in  {-# OPTIONS_GHC #-} pragma: -package-env=lets-lens
  |
3 | {-# OPTIONS_GHC -package-env=lets-lens #-}
  |                ^^^^^^^^^^^^^^^^^^^^^^^^

I do realise that it's tricky to support package-db related commands in OPTIONS_GHC but it'd nevertheless be quite important to support this in some way (possibly with some restrictions) in order to properly support the package-env based workflows (NB: the legacy user pkg-db based ones aren't available anymore in future cabal versions -- package-environments have completely replaced the legacy user-pkg db there).

Trac metadata

Trac field	Value
Version	8.6.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	high
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture