search

mietek / haskell-on-heroku

Buildpack for deploying Haskell apps
BSD 3-Clause "New" or "Revised" License
131 stars 16 forks source link

Not detecting a sandbox change? #58

Closed mohanzhang closed 9 years ago

mohanzhang commented 9 years ago

I'm trying to understand a problem I'm having before resorting to the nuclear option of blowing away the sandbox in my private storage and forcing a build from scratch.

The issue is that my cabal.config is from stackage, so it has many more packages than I actually use in my project's cabal file under build-depends. In my last change, I needed to add a package to build-depends that was already specified under cabal.config (specifically, mime-mail-ses).

I assumed that this would cause a checksum failure and force a new sandbox, but instead, I think the buildpack didn't realize that the sandbox should change, because I see that it selects the sandbox it used in the previous build, even though the constraints are different.

remote: -----> Restoring sandbox directory
remote:        Downloading s3://../linux-ubuntu-14.04-x86_64/ghc-7.10.1/halcyon-sandbox-6a5ba40.5aff4ef-hq-0.0.6.tar.gz... done
remote:        Extracting halcyon-sandbox-6a5ba40.5aff4ef-hq-0.0.6.tar.gz... done, 332MB
remote:    *** WARNING: Unexpected constraints difference
remote:        @@ -1,1332 +1,200 @@
remote:        -AC-Vector-2.3.2
remote:        -Agda-2.4.2.3
(... continues like this for a bunch of lines)

The error I am now getting is:

remote: -----> Configuring app
remote:        Using a sandbox located at /app/sandbox
remote:        /app/ghc/bin/ghc --numeric-version
remote:        looking for tool ghc-pkg near compiler in /app/ghc/bin
remote:        found ghc-pkg in /app/ghc/bin/ghc-pkg
remote:        /app/ghc/bin/ghc-pkg --version
remote:        /app/ghc/bin/ghc --supported-languages
remote:        /app/ghc/bin/ghc --info
remote:        Reading available packages...
remote:        Choosing modular solver.
remote:        Resolving dependencies...
remote:        Could not resolve dependencies:
remote:        trying: hq-0.0.6 (user goal)
remote:        next goal: mime-mail-ses (dependency of hq-0.0.6)
remote:        Dependency tree exhaustively searched.
remote:        Configuring hq-0.0.6...
remote:        cabal: At least the following dependencies are missing:
remote:        mime-mail-ses -any
remote:    *** ERROR: Failed to configure app
remote:    *** ERROR: Failed to deploy app
remote:
remote:  !     Push rejected, failed to compile Haskell app

I'm assuming there is a gap in my understanding of how halcyon uses cabal.config. My immediate reaction is to blow away the sandboxes in private storage to force a rebuild, but is it the best way?

mietek commented 9 years ago

… even though the constraints are different.

The difference is only in your project’s Cabal package description file (*.cabal), which Halcyon does not attempt to parse. Therefore, Halcyon doesn’t see a difference in constraints, and so, forcing a sandbox rebuild is, sadly, the only way to proceed.

If you declare only the packages you actually use, either in a .halcyon/constraints or a cabal.config, adding one more package (without changing the previously-declared constraints) should cause Halcyon to automatically extend the existing sandbox, by building only the newly-added package.

mohanzhang commented 9 years ago

Ah, fantastic. This makes perfect sense. Thank you!