"stack build" succeeds, but "stack build --only-configure" fails

[luigy]

> 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 missing

the 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

[snoyberg]

That's actually the documented behavior:

  --only-configure         Only perform the configure step, not any builds.
                           Intended for tool usage, may break when used on
                           multiple packages at once!

Usage of the --only-configure is 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]

hmm, I see... It was actually using ghc-mod that I ran into this
to get the expected behavior currently I have to be explicit:

stack build servant-0.5
stack build servant-client-0.5
stack build servant-server-0.5
stack build --only-configure

pinging @DanielG for some feedback

I feel like I should close this issue and open one in ghc-mod instead?

[DanielG]

We always call stack build --only-dependencies before calling --only-configure so it's-not-my-fault^TM ;)

See: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L240

[snoyberg]

As mentioned in the original issue, and in the stack build --help output, 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-dependencies would not build wai (since it's a target, not a dependency) whereas stack build --only-dependencies warp would 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]

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]

@luigy Can you share you project's stack.yaml file?

@DanielG it all depends on the directory hierarchy.

[luigy]

using stack @ 7153be8 project was just scaffolded using stack new i-fail-when-only-configure and 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-configure it also triggers the unregistering

[snoyberg]

Can you set extra-dep: true on your Git package?

[luigy]

Almost, now I get this also with just stack build

stack build servant-server-0.5 does install greet successfully, though

flags: {}
packages:
- '.'
- location:
    git: https://github.com/aaronlevin/servant.git
    commit: 48a5d1474aab40ad1fe79353a23f8abc428be90c
  subdirs:
    - servant
    - servant-server
    - servant-client
  extra-dep: true
extra-deps: []
resolver: lts-3.3

[snoyberg]

That's a separate issue, thanks for reporting. I've fixed it on master.

[luigy]

Thanks! executables are fixed now

The "unregistering" still happens though, unless I run it twice, strange

[snoyberg]

That's a known issue, #838, which is being worked on currently.

[luigy]

Nice! 11e02a8 fixes the "unregistering"