stack install PKG-VERSION may quietly install some other version #5112
Labels
Comments
simonmichael
added a commit
to simonmichael/hledger
that referenced
this issue
Dec 3, 2019
|
Thanks for reporting! This seems to be an edge case, glossed over in the documentation — in short, as Given this, plus your expectations, would you like to see stack throw an error, indicating what is actually going on? |
|
I've always understood |
|
I didn't look deep into it but I think that this could be a reason for this to happen - stack/src/Stack/Build/ConstructPlan.hs Line 715 in 9e6fd9f Unfortunately it doesn't list complete motivation behind this decision and I think I've talked with @snoyberg about it at least once but I don't remember enough details of that either. Actually that line is about dependencies and in this case it's an explicit target so that could be an explanation to no warning issued. I agree that this behavior is at least confusing and it makes sense to investigate it better and at least document it. |
Oh definitely never the right behaviour. The snippet from Seems like we're all happy to call this a bug. I think the correct behaviour is to throw an error indicating that the package is in the snapshot, so cannot be overridden, and providing a link to how to use a custom snapshot. @simonmichael Would you be wiling to help dig further into this, and resolve the matter? |
|
For this use case - outside a project, installing an app that’s not yet in stackage but compatible - I feel it could do better than that. It works fine if you’ve done a stack update.
|
Ah, I didn't realize that. Would you be able to paste some verbose logs? |
|
Forgive me, I just wanted to note the issue; I think it’s easy to reproduce.
|
|
@dbaynard, I just hit this again, here's the -v log: |
|
And here's a second oddity. After stack update, the newer binary is installed, as expected: But ghc-pkg list is still showing the old version. Note the hash below is different from the one in the "Installing library in.." line above. I'm not sure why. |
Because of the default resolver in this project being lts-14.16, I suppose. Disregard this side issue then. [Maybe relevant to the main issue too ?] |
|
I also came across this behavior recently: I requested package |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
Outside a project, ask stack install to install a package version that it doesn't know about yet (because stack update wasn't run recently):
Expected
I expected it to find the requested version (1.16.1) from hackage, perhaps automatically updating its package db first; or to complain that it didn't know about this version, and fail with an error, and suggest running stack update.
Actual
It installed an older version (1.14.1) (the latest known at time of last stack update, presumably), and reported no error.
Stack version
The text was updated successfully, but these errors were encountered: