Repository navigation
"stack build" succeeds, but "stack build --only-configure" fails #920
Description
> stack build
servant-0.5: build
servant-0.5: install
servant-client-0.5: configure
servant-client-0.5: build
servant-server-0.5: configure
servant-server-0.5: build
servant-client-0.5: install
i-fail-when-only-configure-0.1.0.0: configure
i-fail-when-only-configure-0.1.0.0: build
i-fail-when-only-configure-0.1.0.0: install
servant-server-0.5: install
servant-server-0.5: install
Completed all 4 actions.> stack build --only-configure
Progress: 3/4singleBuild: invariant violated, missing package ID missing
singleBuild: invariant violated, missing package ID missingthe missing package ID is servant-0.5
(maybe stack should probably show the package ID instead of just "missing" as well?)
# stack.yaml
flags: {}
packages:
- '.'
- location:
git: https://github.com/aaronlevin/servant.git
commit: 48a5d1474aab40ad1fe79353a23f8abc428be90c
subdirs:
- servant
- servant-client
- servant-server
extra-deps: []
resolver: lts-3.3
Activity
snoyberg commentedon Sep 4, 2015
That's actually the documented behavior:
Usage of the
--only-configureis intended exclusively for tools that rely on some internal Cabal files, and should not be used by most people. See #820 for the discussion. What's the use case that you're using it?luigy commentedon Sep 4, 2015
hmm, I see... It was actually using
ghc-modthat I ran into thisto get the expected behavior currently I have to be explicit:
pinging @DanielG for some feedback
I feel like I should close this issue and open one in
ghc-modinstead?DanielG commentedon Sep 4, 2015
We always call
stack build --only-dependenciesbefore calling--only-configureso it's-not-my-fault^TM ;)See: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L240
snoyberg commentedon Sep 6, 2015
As mentioned in the original issue, and in the
stack build --helpoutput, this is not the way the feature is designed to work, you need to give it just a single target package for reliable results. Taking the wai project as an example,stack build --only-dependencieswould not build wai (since it's a target, not a dependency) whereasstack build --only-dependencies warpwould build wai (since it's no longer a dependency). stack has no way of knowing which package you're trying to get it to build.Perhaps the call should be
stack build --only-dependencies . && stack build --only-configure .to just build things in the current directory?DanielG commentedon Sep 7, 2015
We don't support multi-package stack projects yet though (going to add that now). We only apply this stuff when the stack file is next to the cabal file, so in the case where there are multiple packages this shouldn't even run. Are the commands in that case equivalent to the ones without
"."at the end or is there a difference?snoyberg commentedon Sep 7, 2015
@luigy Can you share you project's stack.yaml file?
@DanielG it all depends on the directory hierarchy.
luigy commentedon Sep 7, 2015
using stack @ 7153be8 project was just scaffolded using
stack new i-fail-when-only-configureand slightly modified here stack.yaml and i-fail-when-only-configure.cabal@snoyberg I find this unregistering odd. Is it expected? something about local vs snapshot dbs?
I would expect noop but, even when I
stack build . && stack build . --only-configureit also triggers the unregisteringsnoyberg commentedon Sep 7, 2015
Can you set
extra-dep: trueon your Git package?luigy commentedon Sep 7, 2015
Almost, now I get this also with just
stack buildstack build servant-server-0.5does install greet successfully, thoughsnoyberg commentedon Sep 7, 2015
That's a separate issue, thanks for reporting. I've fixed it on master.
Build executables for local extra dpes #920
luigy commentedon Sep 7, 2015
Thanks! executables are fixed now
The "unregistering" still happens though, unless I run it twice, strange
snoyberg commentedon Sep 7, 2015
That's a known issue, #838, which is being worked on currently.
luigy commentedon Sep 20, 2015
Nice! 11e02a8 fixes the "unregistering"