cannot compile yesod, hGetContents invalid argument

Solution 1:

Well, let's try again...

Short answer: Before the stack build, set your encoding to en_US.UTF-8 or any other UTF-8-enabled encoding, either system-wide by editing /etc/locale.conf:

# /etc/locale.conf
LANG=en_US.UTF-8

or by setting it in the shell:

$ export LANG=en_US.UTF-8
$ cd someproj
$ stack build

Long explanation: It looks like you've run up against a bug for which no one ... will accept ... responsibility.

The file Grammar7.y in the package language-javascript contains a single UTF-8 character, so it needs to be read by the Happy parser using UTF-8 encoding. However, by default, Happy reads its input files using the system encoding from the locale, and the Happy folks think that's the correct behavior.

Both Cabal and Stack are supposed to reliably build source packages downloaded from the Internet on local machines, and so they ought to build packages by reading source files using the encoding of the source files, rather than the encoding from the local machine's locale.

For Haskell source files, there's no problem because GHC ignores any system encoding and reads all source files as UTF-8 encoding. This is the sensible thing for a compiler/interpreter/language-standard/etc. to do in our Internet-connected age -- either specify a fixed encoding for all source files (e.g., GHC, Python) or provide a mechanism to specify the encoding in the file itself (e.g., HTML, LaTeX, etc.).

Since Grammar7.y is a Happy file, and the Happy folks have chosen the non-sensible approach, it falls to either Stack or Cabal to ensure that -- during the build process -- non-Haskell source files are read with the correct encoding. They could do this by either decreeing that Stack and Cabal will always build packages with the system encoding overridden to UTF-8, or by providing some mechanism in the xxx.cabal file for specifying the package's encoding and setting it on a per-package basis. Unfortunately, neither group of developers wants to accept this responsibility.

So, we're stuck in an ridiculous situation where Stack can only reliably build packages when the system locale is configured for UTF-8 encoding, but the Stack developers think Stack shouldn't override the system locale during builds to ensure it's configured for UTF-8 encoding.