A case when stack does not rebuild but I think it should

[harendra-kumar]

I have a path-io specified as a local package with extra-dep as true in a package called path-test:

packages:
- '.'
- location: ../../github/path-io
  extra-dep: true

path-io has a stack.yaml of its own and when I make changes in that package I first build and test it using that stack.yaml. After that if I come back to the path-test package and do a stack build then it does not rebuild. If I do a stack clean in the path-io package (i.e. using path-io's stack-yaml) and then do a stack build in path-test then it rebuilds fine.

I am not sure why the path-test setup gets impacted by the path-io setup or whether it should.

[mgsloan]

There may not be any bugs here, as long as it's using the exact same dependencies. Definitely something that should get tested more!

Is it not rebuilding when there's definitely a difference in the build?

[harendra-kumar]

Yes, any new changes in path-io do not reflect in the path-test executable because it does not get rebuilt at all if I built path-io independently earlier.

Is there some hack workaround, that doesn't involve stack clean, such as telling each stack build to use its own package dbs?

I will try --force-dirty. Also, I may not be using stack properly, as it might require that I increase the version number of the package (e.g. path-io) in its cabal header, so that downstream packages know that the package has changed?

Bumping cabal version is a sufficient work around for now for me. --force-dirty didn't save much time relative to stack clean. stack might be behaving correctly by assuming that an upstream library did not need to be rebuilt unless its version number changed. Consider closing this issue and documenting that behavior instead.

[mpilgrem]

I am closing this given the passage of time and because extra-deps are no longer specified using the packages key.