Temporarily building against a "shadowing" local package? #992
Comments
|
I confirm the bug |
|
I've been tracking down a number of bugs all around a similar concept here, but unfortunately haven't been able to reproduce any of them (this included). Can you provide the |
|
Sure. I can reproduce it with HEAD @ c0525a2. junk.cabal stack.yaml (1) flags: {}
packages:
- '.'
extra-deps: []
resolver: lts-3.4stack -v build (1) stack.yaml (2) flags: {}
packages:
- '.'
- '/Users/mrosen/haskell/persistent/persistent'
extra-deps: []
resolver: lts-3.4stack -v build (2) stack.yaml (3) -- same as (1) flags: {}
packages:
- '.'
extra-deps: []
resolver: lts-3.4stack -v build (3) |
|
@rvion What OS are you using? |
|
I was able to reproduce this finally with some help. Here's the problem: the installed package ID is not unique, and the exact same one is being used in both the snapshot and local databases. This means that when we say "I want persistent-template-deadbeef", it's completely ambiguous whether we mean the one in the snapshot or local database. GHC will choose the one in the later package database (which is the local one), which depends on the local copy of persistent, which we're no longer building against. @mitchellwrosen your comment about unregistering seems like the right resolution here, though I'd prefer if there was a way to tell GHC much more directly which installed package we want. The problem here is that GHC can distinguish between two installed copies, but there's seemingly nothing we can say on the command line to make that distinction. |
snoyberg
added a commit
that referenced
this issue
Sep 16, 2015
|
I think this is now resolved, can you give it a shot on master? |
|
Yes, sorry I didn't make myself clear in the original post. I meant to point out that it's curious Anyways, that was fast! I'll try a bit later today. |
|
@snoyberg on OSX (10.11) |
|
@snoyberg Fixed for me. Thank you sir! |
|
Pleasure, glad it's working! Now just debating whether I should open up a Cabal bug report about the matching installed package ID issue. |
|
Upstream issue reported: haskell/cabal#2830 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found a way to confuse
stackand require a manual removal of the local package database, or something to that effect. I haven't worked out all the details, but basically what I've done is this:persistentandpersistent-templateas dependencies (usinglts-3.4, this brings inpersistent-2.2andpersistent-template-2.1.3.4:persistentlocally and build against it, so I git clone it and add/path/to/local/persistentto my stack.yaml'spackagespersistent-templateto rebuild and depend on this localpersistent.persistent, so I delete the line from stack.yamlI think I'm getting this error because
junkis unregistered before rebuilding, but my localpersistent-templateandpersistentare not. Thus,junkgoes to depend on the snapshotpersistent-2.2-7814fec4f4ee40ea6b1f627410f1c9eb, while my localpersistent-templatestill depends on the localpersistent-2.2-3dd9b8c4bcaf5265acba55fc4993f288.I haven't figured out how to get out of this situation without
rm -rfing the local package db and rebuilding.Deleting local packages from stack.yaml and expecting stack to work 100% correctly might be asking too much. I know stack doesn't attempt to be any sort of package manager, nor support any cleaning up of build artifacts. Still, I don't feel I did anything too out the ordinary with temporarily shadowing a snapshot package with a local one. If anything, a
stack clean && stack buildshould have "just worked", butstack cleandoesn't appear to do anything :)The text was updated successfully, but these errors were encountered: