This may have some relation to #2070 - the ability to ensure that we are always using the same cabal file.
As discussed here, it extra-deps cause the hackage cache to get loaded, as we need to get their cabal description. I haven't thought through all the details, but this doesn't seem necessary. The fix may be complicated, though:
There are two spots that need the cabal file:
|
p <- liftIO $ loadPackage ctx name version flags |
|
package <- liftIO $ loadPackage ctx name version flags |
In the case that we already have this package installed, there should be enough info in the package db, potentially even in ghc-pkg queries stack already made, to not need to load the cache.
We're going to be swapping out binary with faster serialization soon, so it may be that soon there won't be as much motivation for doing something sophisticated to avoid this 0.3s load time.
This may have some relation to #2070 - the ability to ensure that we are always using the same cabal file.
As discussed here, it extra-deps cause the hackage cache to get loaded, as we need to get their cabal description. I haven't thought through all the details, but this doesn't seem necessary. The fix may be complicated, though:
There are two spots that need the cabal file:
stack/src/Stack/Build/ConstructPlan.hs
Line 286 in dd98fbc
stack/src/Stack/Build/ConstructPlan.hs
Line 320 in dd98fbc
In the case that we already have this package installed, there should be enough info in the package db, potentially even in
ghc-pkgqueries stack already made, to not need to load the cache.We're going to be swapping out
binarywith faster serialization soon, so it may be that soon there won't be as much motivation for doing something sophisticated to avoid this 0.3s load time.