Stack requires presence of extra-deps even when not needed for target, or, cannot specify extra-deps at build-time

[acfoltzer]

Minimal example: a project that includes two packages:

• a Haskell code generator generator that only depends on base
• a package foo that depends on base and the generated package generated

Since foo won't build without its dependencies listed in stack.yaml, I have to list generated in stack.yaml, but running Stack commands without that package in place fails even if that package is not needed for the requested target.

Steps to reproduce

• Set up the directory:

% tree
.
├── foo
│   ├── ...
│   └── foo.cabal
├── generator
│   ├── ...
│   └── generator.cabal
└── stack.yaml
% cat stack.yaml
resolver: lts-5.1
packages:
- location: foo/
- location: generator/
  extra-dep: true
- location: generated/
  extra-dep: true
% cat foo/foo.cabal
name:                foo
[...]
library
  build-depends:       base >=4.7 && <5,
                       generated

• stack build generator --exec 'generator --build-me-some-code -o generated'
• stack build foo

Expected

I expect Stack to build the generator executable, and then run it to produce a cabal package in /generated, so that I can then build foo now that its dependency exists.

Actual

% stack build generator --exec 'generator --build-me-some-code -o generated'
Could not resolve directory /private/tmp/ex/generated/

I can create the empty directory, but then Stack wants a cabal file:

% mkdir generated
% stack build generator --exec 'generator --build-me-some-code -o generated'
No .cabal file found in directory /private/tmp/ex/generated/

---

Alternate scenario

I could imagine not including generated in the stack.yaml, but instead being able to pass it as a dependency when running stack build foo.

[harendra-kumar]

hmm, interesting use case. Currently stack requires all packages to have a valid cabal file present which is not possible in this case. We could ignore the missing cabal files as long as they are not needed for building the requested target. Once that is done your two step build should work as expected.

This should be fixed. A related issue is #1722 , perhaps both of these can be fixed together.

Until this is fixed you can try a workaround using two stack.yaml files, one to only generate the code (without having foo in it) and another one using the generated code. You can use --stack-yaml to select the appropriate stack.yaml. For example stack build foo --stack-yaml stack.foo.yaml .

[mgsloan]

I agree that it would be ideal to support this usecase. This might be resolved by #1265 , something to consider when it's implemented.

Normal entries in the extra-deps list are used lazily (which actually means errors in it aren't readily detected - #1521). I suspect that these are being treated differently since they're part of the packages list.

[mgsloan]

I don't think this will be resolved. In order to figure out what packages are present in the project, all cabal files must be present.