Repository navigation
Local version of package is not rebuild / removed #2147
Description
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 inextra-deps, nothing changes either - Even if I do a
stack cleanit 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.
Activity
mgsloan commentedon May 16, 2016
Is the file you've modified mentioned in
exposed-modulesorother-modulesin your cabal file? When you do build the package are there warnings about unlisted modules?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 commentedon May 16, 2016
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
packagesand put theextra-depsone back, trying to go back to using the officil release. Didn't get a rebuild, did astack clean, still had the local modified version. Only after deleting.stack-workdid I get a build/configure step forthreepennyand the release version again.mgsloan commentedon May 16, 2016
Thanks! Giving it a try.
blitzcode commentedon May 16, 2016
What made me pause was that I actually do get a configure/build step for
threepennyafter 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 commentedon May 16, 2016
EDIT: Nvm, I can reproduce. Looks like the issue is only when the local package version matches what was in extra-deps.
blitzcode commentedon May 16, 2016
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
threepennyas a local package. The application continues to rebuild, but changes inthreepennyare not picked up. Then, if I remove the local version ofthreepennyand add the hackage dependency onthreepennyagain, nothing is picked up either. Even if Istack cleanand rebuild the entire project, I still get the old local version ofthreepenny. Only deleting.stack-workmakes it go back to using the version downloaded from hackage, which is then rebuild instead of take from the cache.mgsloan commentedon May 16, 2016
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 commentedon May 16, 2016
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 commentedon May 16, 2016
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 commentedon May 17, 2016
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.
Have ConfigCache distinguish between local and upstream src #2147
mgsloan commentedon Apr 20, 2017
Finally fixed! Wish I'd seen that the fix was so straightforward.
ChangeLog entry for #2147
nh2 commentedon Apr 23, 2017
Second part of fix for stack not noticing switches between
packagesandlocation extra-deps: 4179967