[GHC] #15541: package environment files and the GHC API

[GHC]

#15541: package environment files and the GHC API
-------------------------------------+-------------------------------------
        Reporter:  lspitzner         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.6.1
       Component:  GHC API           |              Version:  8.4.3
      Resolution:                    |             Keywords:  package
                                     |  environment
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Documentation     |  Unknown/Multiple
  bug                                |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15513            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by lspitzner):

 > The motivation for this design is that package environments should be
 transparent to the user, giving tooling a means of configuring GHC for a
 project without further user intervention.

 I consider the whole feature to be a mistake, see
 [https://hexagoxel.de/postsforpublish/posts/2018-08-25-ghc-pkg-env-
 misfeature.html this summary post].

 As a consequence, if I had to choose between the options you presented,
 I'd vote for the first (rip out this side-effect from
 `setSessionDynFlags`).

 Some further opinionated thoughts:

 - If you expose `getFoo` and `setFoo`, `getFoo >>= setFoo` **must behave
 as identity**, free of (side- / other) effects. No amount of API docs
 excuses a violation.
 - It is likely to surprise and generally inadvisable to have any actions
 exposed in an API depend on `CWD`, especially by default.
 - The actions in the API should all have a single, clearly defined
 purpose.

 In brittany we encountered exactly the same question when it came to user
 config handling in its API. Perhaps have a look at how the brittany API is
 designed when it comes to `Config` values:
 https://hackage.haskell.org/package/brittany-0.11.0.0/docs/Language-
 Haskell-Brittany.html. Note how `parsePrintModule` is explicit about its
 inputs, promises to be semantically pure, and that there are separate
 actions that explicitly handle the filesystem reading of config files.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15541#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler