Have stack run "ghc-pkg check"

[mgsloan]

It seems like a good idea to run ghc-pkg check periodically. I just got this error message (not sure what the cause is):

    Building quickcheck-io-0.1.2...
    Preprocessing library quickcheck-io-0.1.2...

    /tmp/stack7730/quickcheck-io-0.1.2/src/Test/QuickCheck/IO.hs:7:18:
        Could not find module ‘Test.QuickCheck.Property’
        There are files missing in the ‘QuickCheck-2.8.1@Quick_8UnGnTXfSEEClQczG6tI7s’ package,
        try running 'ghc-pkg check'.
        Use -v to see a list of the files searched for.

Indeed, ghc-pkg check --simple-output yields a list of broken packages. Presumably we're trying to avoid ghc-pkg check yielding any broken packages (always unregistering things that get broken).

Sidenote: We should really have a way to reinstall snapshot packages in this circumstance: #1476

I think the best approach to this would be to run ghc-pkg check --simple-output at the beginning of the build command execution, and compare with the output at the end of execution (even if an exception is thrown). If packages are freshly broken, complain loudly.

One question is whether this should be done by default - it could have quite a bit of runtime overhead. We could have some stack.yaml flag like dev-mode: True which enables costly checks and assertions and such (intended to be specified in the global stack.yaml).

[bollu]

Hey, I'm receiving this error right now:

cellular-automata-diagrams [master●●] stack build
haskell-diagrams-cellular-automata-0.1.0.0: build
Preprocessing library haskell-diagrams-cellular-automata-0.1.0.0...

/Users/bollu/work/cellular-automata-diagrams/src/Cellular.hs:38:8:
    Could not find module ‘Data.Vector.Strategies’
    There are files missing in the ‘vector-strategies-0.4@vecto_CXFpmzMRl3CEXjIZDHLF8l’ package,
    try running 'ghc-pkg check'.
    Use -v to see a list of the files searched for.

--  While building package haskell-diagrams-cellular-automata-0.1.0.0 using:
      /Users/bollu/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:haskell-diagrams-cellular-automata exe:haskell-diagrams-cellular-automata-exe --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

I'm somewhat lost: how do I fix this? Nuke the .stack-work folder? or something else?

[mgsloan]

@bollu One option is to run stack exec -- ghc-pkg unregister vector-strategies

[bollu]

Thanks, that worked!
Also, any idea why this happened?

On Wed, 5 Oct 2016 at 05:00 Michael Sloan [email protected] wrote:

@bollu https://github.com/bollu One option is to run stack exec --
ghc-pkg unregister vector-strategies

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1811 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABncjZuCe4pdkGZgOSGvvVL6kZJpwiPyks5qwuGcgaJpZM4HegW7
.

Sending this from my phone, please excuse any typos!

[mgsloan]

Not sure, my theory is that it occurs when a process gets terminated in the midst of writing out some file / set of files. It's quite likely that Cabal or ghc's error handling in these circumstances are imperfect.

One of the reason to do this ghc-pkg check would be to identify the exact circumstance where things go wrong.

[danse]

same happened to me and i fixed by unregistering. since i was using a turtle script with stack as interpreter i specified the related resolver from the command line:

stack exec --resolver lts-10.10 -- ghc-pkg unregister <package>

[cebaa]

@mgsloan "my theory is that it occurs when a process gets terminated in the midst of writing out some file"

Two more theories:

• Antivirus
• Two stack install running at the same time

The unregister workaround worked in my case as well. The number of times (probably like 40) I had to do this (for various different packages) while installing a single library (turtle, installing from its source to test an update to this issue) was considerable though, so I'm betting on the antivirus theory. :)

[danse]

Two stack install running at the same time

This is interesting... aren't concurrent runs supported? I've been wondering the same also about other package/dependency management/build tools ... i wonder about the expectations users have about this, since usually we run such commands one at a time, while with more advanced usage it becomes common to run multiple related commands in parallel

[cebaa]

@danse I am not sure, just throwing it out as a potential cause, since when things broke for me, I had two of them running. I'm still betting on the antivirus :)

[danse]

not familiar with stack's code, withUserFileLock seems to indicate that assets are exclusively managed by one process at a time