Setup.hs cannot use local snapshot dependencies WAS stack failing to resolve local dependencies of multiple package project #897
Comments
|
The reason this is happening is that, currently, we only allow the Setup.hs file to use global and snapshot packages, not local packages. The reason is reproducible builds: relying on something in the local database means that a build today may fail later if the local database is in a different state. I'm open to relaxing this. There's even a comment about all of this in the codebase at: https://github.com/commercialhaskell/stack/blob/master/src/Stack/Build/Execute.hs#L678. I think the best course of action here is to add |
|
I'm not sure I understand. This repo has two packages, the second of which depends on the first in its Setup.hs, and it builds successfully: https://github.com/mitchellwrosen/stack-897-example |
|
That's because you've set |
|
I see. Sure, I can attempt that change but it might take a bit =) |
|
If you get stuck, let me know. Initial version would just be adding |
|
Well, that was simple enough, and it did fix the problem. So, bigger picture, I don't really have a strong opinion about which package databases Setup.hs has. The comment in the source code about |
|
You interested in taking a crack at implementing that? I don't foresee any obstacles, especially since the list of available dependencies is already populated at this point in the build process. |
|
Sure. Where is the list of available dependencies? =) |
|
Just walked out of the house so I can't show you the exact code. Look in On Wed, Sep 2, 2015, 8:51 AM Mitchell Rosen notifications@github.com
|
|
Ok, here's a first attempt: #899 |
|
A couple days ago, Duncan mentioned that cabal plans to have build dependencies for Setup.hs, like this: haskell/cabal#948 For now, it does seem like a reasonable idea to use the same set of packages as the package itself + Cabal. |
snoyberg
changed the title
Give Setup.hs all project dependencies #897
|
So it would seem. Blast from the past :) |
|
The present for me :-) |
|
What happens if you manually install the dependencies with On Mon, Sep 19, 2016 at 8:03 PM, Andrés Sicard-Ramírez <
|
|
After installing |
|
I've added an answer at: http://stackoverflow.com/a/39579714/369198 |
|
Your answer above fixed the problem. Thanks! |
Hi, I can't seem to reproduce this with a smaller example repo so I'll just point to the one that's failing: https://github.com/mitchellwrosen/cabal-macosx/tree/b6e5f714fbf451a72c8b7e70577ce7d9e342f8d0
I'm trying to stackify this three year old repo, and the example projects, which depend on the
cabal-macosx, fail to build:I'm not really sure why;
stack exec ghc-pkg listshowscabal-macosx-0.2.2in.stack-work/install/x86_64-osx/lts-3.3/7.10.2/pkgdb, andstack exec ghc-pkg describe cabal-macosxlistsDistribution.MacOSXas an exposed module. And as I said, I couldn't replicate this with a simpler multiple-package example.Here's the entire
stack -v buildin case any of it is relevant:The text was updated successfully, but these errors were encountered: