Stack unregisters and rebuilds all the extra-deps with each new (dev) stack version

[sjakobi]

While developing on stack, I see the following whenever I build a new executable:

~/s/stack $ stack install --fast --ghc-options -j
stack-1.1.3: unregistering
store-0.1.0.1: unregistering (missing dependencies: th-lift-instances, th-orphans, th-utilities)
th-lift-instances-0.1.7: unregistering (old configure information not found)
th-orphans-0.13.1: unregistering (missing dependencies: th-lift-instances)
th-utilities-0.1.1.0: unregistering (missing dependencies: th-orphans)
th-lift-instances-0.1.7: configure
th-lift-instances-0.1.7: build
path-0.5.8: configure
path-0.5.8: build
th-lift-instances-0.1.7: copy/register
th-orphans-0.13.1: configure
path-0.5.8: copy/register
th-orphans-0.13.1: build
path-io-1.1.0: configure
path-io-1.1.0: build
path-io-1.1.0: copy/register
th-orphans-0.13.1: copy/register
th-utilities-0.1.1.0: configure
th-utilities-0.1.1.0: build
th-utilities-0.1.1.0: copy/register
store-0.1.0.1: configure
store-0.1.0.1: build

I think this is due to some versioning feature in store. It's really annoying though.

[mgsloan]

Agreed, this is really annoying, I was aware of a more restricted version of this with ghci - mgsloan/store#53 . A simple fix is possible, but it would just be a patch to something that's a bit iffy anyway (good for original app, not so good for stack). A more comprehensive fix is in progress.

It is certainly something I intend to fix before any release with the store-ified stack.

I didn't realize it happened with each new dev version. I thought it was just when dependencies involved in the type info change, or if you use ghci to load stack.

[sjakobi]

Hypothesis from #2353:

It seems like perhaps the git hash for the stack binary is causing such invalidation.

[mgsloan]

I've got a branch. Pending release of store / etc.

[sjakobi]

Looks like this was fixed in #2425 and can be closed!?

Awesome work, @mgsloan! 👏

[mgsloan]

Yup! Thanks!