Local version of package is not rebuild / removed

[blitzcode]

I have a dependencies on a package that's not in Stackage. I specify an extra-deps. Works as expected. If I now remove it from the extra-deps, download the source from GitHub and add it in packages, it is rebuild and the local, modified version is used. So far so good. But:

• If I modify the local package and then rebuild my project, the changes are not rebuild, not picked up
• If I delete the local package, remove it from packages, put the Hackage version back in extra-deps, nothing changes either
• Even if I do a stack clean it still seems to link to whatever binary of the local package it had

Only deleting .stack-work makes it pick up on the changes and rebuild & link the Hackage version again. This is with stack v1.1.0 on OS X 10.10.

[mgsloan]

If I modify the local package and then rebuild my project, the changes are not rebuild, not picked up

Is the file you've modified mentioned in exposed-modules or other-modules in your cabal file? When you do build the package are there warnings about unlisted modules?

If I delete the local package, remove it from packages, put the Hackage version back in extra-deps, nothing changes either

That's extremely mysterious.

I've done a similar workflow many many times, so there must be something weird. While I realize that you've described some general steps to reproduce, can you please put together a list of specific steps? (preferably using packages that don't require 3rd party deps)

[blitzcode]

I'll see if I can make a smaller repo case, but the concrete example is here:

https://github.com/blitzcode/hue-dashboard/blob/v1.1/stack.yaml

I have a single package that's not in Stackage as a dependency. I just had the problem again where I tried with a modified local version of the package, and then removed it from packages and put the extra-deps one back, trying to go back to using the officil release. Didn't get a rebuild, did a stack clean, still had the local modified version. Only after deleting .stack-work did I get a build/configure step for threepenny and the release version again.

[mgsloan]

Thanks! Giving it a try.

[blitzcode]

What made me pause was that I actually do get a configure/build step for threepenny after clearing everything. It should just be in the cache like all the other dependencies, but it seems the local version overwrites it somehow, requiring an actual rebuild?

[mgsloan]

EDIT: Nvm, I can reproduce. Looks like the issue is only when the local package version matches what was in extra-deps.

[blitzcode]

I don't understand, this is just building the project? That's working just fine!

The problem isn't happening with the executable project, it's with the dependency. The application builds/rebuilds etc., the problem only shows if I add threepenny as a local package. The application continues to rebuild, but changes in threepenny are not picked up. Then, if I remove the local version of threepenny and add the hackage dependency on threepenny again, nothing is picked up either. Even if I stack clean and rebuild the entire project, I still get the old local version of threepenny. Only deleting .stack-work makes it go back to using the version downloaded from hackage, which is then rebuild instead of take from the cache.

[mgsloan]

Yeah, sorry, I was going a little quick with the repro. I do indeed see the issue, and have updated my comment. Thanks for reporting the problem and providing a repro!

[mgsloan]

Ok, so far I cannot reproduce the issue with dirty modules in threepenny not causing build. Are you sure about that part? It could be that this is fixed in HEAD, I recently fixed a bug with missing files in the dirtiness checker.

I can reproduce the issue where switching from local package to extra-dep with matching version doesn't cause a build.

[mgsloan]

I think this may be solved as a consequence of #1265

Since that's coming soon-ish, I'll come back to this issue after.

[blitzcode]

I tried with v1.1.0 installed from brew, but I also didn't try too hard to pin down the rebuild issue. I was mostly concerned with not being able to easily go back to the hackage dependency. I'll add some more detail when I try to work with the external package next, soon-ish.