Repository navigation
Local extra-dep should not be considered $locals #3574
Description
Using stack installed with --git on Windows 10 64bit, version:
Version 1.6.0, Git revision 46121be1b96465f1164e3f84cafa19c7369da9cc x86_64 hpack-0.18.1
Given stack-bug.zip, that defines in the stack.yaml:
packages:
- location: foo
extra-deps: true
ghc-options:
$locals: -bob
When compiling foo I don't expect the flag -bob to be applied as foo is an extra-dep, and thus not a local package. However, when I stack build I get an error about:
ghc.EXE: unrecognised flag: -bob
Activity
mgsloan commentedon Nov 14, 2017
extra-depsis perhaps not the best name, a bit of a historical artifact. It would be nice to improve the stack documentation to describe the terminology properly. Or, perhaps, change the behavior to be less surprising."extra-dep" essentially just means "not a target by default". Currently, they are always considered local packages. Once implicit snapshots is implemented, this wouldn't be the case and the local package vs snapshot package will make even less sense. So I anticipate that the local package distinction will get dropped.
I think
$targetsis closer to the behavior of what you're looking for, but it will also be applied in the case that you dostack build foo, but won't be if you just dostack build.Not sure what to call the non-extra-deps.
default-targets? I guess could add another set of packages specified by the config, based on not being an extra-dep.ndmitchell commentedon Nov 14, 2017
Hmm,
extra-depsis indeed a terrible name - we've used it completely incorrectly. Can I suggest adding definitions of$localsand the other$variablesto yaml_configuration.md. Note that defining custom ghc-options makes something a$locals(I think). I did read the docs, and came to the conclusion (perhaps from extra-deps elsewhere on the page) that the behaviour is wrong.FWIW
$default-targetswas exactly what I wanted, but following #3573 it's not as important, and given theextra-depsterminology elsewhere$default-targetswould be reasonably confusing.snoyberg commentedon Nov 22, 2017
First things first: the correct syntax is to say
extra-dep: trueinstead ofextra-deps: true. In fact, if I runstack buildin this directory, I see:Changing to
extra-dep: truegets me:And then
stack build foogets the error in question.I think this is just a bug in implementation: I would not consider any extra-dep packages to be locals, and think it's just a bug in the code base. My understanding and reading of the docs have always gone in that direction. @mgsloan are you inherently opposed to just fixing the implementation such that
$localsonly applies to actual local packages?mgsloan commentedon Nov 23, 2017
@snoyberg I am not opposed to that. I think part of the root of this is that IIRC, the
LocalPackagetype is also used for git packages, I suppose since the code is always available locally. It might actually be nice to reduce the distinctions between snapshot and local packages, keeping track of unpacked snapshot source. I don't think this would work for wired in packages / other packages that come with ghc, so that could be tricky.. It'd have the following advantages:In fact, I think it would be good to take this as an opportunity to consolidate / define stack's terminology around different sorts of packages. Currently we have: the following terms
Would also be good to include along with the docs for this terminology, also the terminology for DBs, even though that's an implementation detail. It would be good to explain global DB vs snapshot DB vs local DB.
snoyberg commentedon Nov 23, 2017
I think we're mostly on the same page, see #3352. For now, I'm going to make changes necessary so this specific case passes.
Don't apply to extra-deps #3574
Don't apply to extra-deps #3574
snoyberg commentedon Nov 23, 2017
PR #3601 is now open
Don't apply $locals to extra-deps #3574
Merge pull request #3601 from commercialhaskell/3574-extra-dep-locals
snoyberg commentedon Aug 23, 2018
This was already addressed by #3601, closing.