Unable to configure 'entropy' when depending on newer 'unix' #1110
Comments
|
Would you be able to try upgrading to Cabal 1.22? This looks similar to #1090. |
|
I just tried, but I get the same error: |
|
Note that if you look at the actual command that is run, it doesn't specify the package ids for process and directory. If you compare with the command when |
|
Ah, good catch, this is that annoying issue of the packages provided to On Tue, Oct 6, 2015 at 1:05 PM, Erik Hesselink notifications@github.com
|
|
Yeah, hopefully this will get better once Setup.hs build-depends become more widely used, but for now, I guess I'll just keep filing issues as I run into them :/ |
|
Can you confirm that manually editing the entropy package .cabal file to add process and directory as build-depends fixes the problem? |
|
I don't think that feature is even in a released Cabal version yet. Or do you mean just adding it to the normal library build-depends? |
|
Yes, that's what I meant. |
|
Hmm, that gives more errors. Here's what I did:
Should I file that as a separate bug? Then I switched to the latest versions of directory and process ( |
|
I don't think it's worth opening that as an issue, especially since #863 (which I was planning on starting on today) will have a major impact on it. The question then comes down to this issue with entropy. Do we consider Setup.hs being custom and relying on an unlisted global and overridden package something that Stack needs to deal with, or state that modifying entropy like this is the right solution? I really don't know. Pinging @mitchellwrosen for input as well. |
|
At the very least it's confusing that upgrading a seemingly unrelated package ( |
|
I'd also prefer never in an ideal world. But for the "always" case to work, it seems like what we'd need to do is that, for every package with a custom Setup.hs, add an implicit |
|
Why would you need to make them available? These are the packages that come with ghc, they should always be available. The problem seems to be that if there is one in the global db, and one in the project db, it won't be passed. Is that correct? If so, then perhaps you could pick the set of 'core' packages, find the right version (global, snapshot, project) for each one, and pass those versions. Since there should always be a version of a package, that should work, right? |
|
No. Consider the case (which actually occurred in Stackage) where:
If you use just the global packages, you'll get the unmodified X. If you use the modified X and Y from the global database, you'll get mismatched types. The only option is to recompile Y against the modified X and then use that. |
|
Ah, I see. Yeah, in that case adding these dependencies seems good. I don't see the use case for making it configurable (the set that comes with ghc seems good enough) but it probably doesn't hurt, there's always some corner case out there. |
|
Actually, I really can't see a way to implement this that doesn't introduce some kind of major regression for someone. At the very least, it can trigger a whole bunch of unnecessary package installs. I'm beginning to think there's no way to handle this case gracefully, and just documenting the workaround of locally checking out the relevant packages and moving on. |
|
Hmm, that doesn't sound like a great workaround. We're running into this now, and are unable to install our snapshot from scratch now it seems. I've seen at least two packages in our dependencies where we're running into this, and there might be more. I'd rather not maintain lots of forks like that. Perhaps there is a different workaround? Something like keeping all (most?) core packages at their original versions? |
|
How about an option in stack.yaml that says "always use the global package On Tue, Oct 6, 2015 at 3:01 PM, Erik Hesselink notifications@github.com
|
|
That sounds perfect, but I understood from the above that that wasn't possible. I think that should cover most (all?) dependencies for |
|
It will work in many common cases, just not every case. The more unusual On Tue, Oct 6, 2015 at 3:33 PM, Erik Hesselink notifications@github.com
|
|
I've just pushed a commit to master with the new |
|
Yes, works like a charm! Both setting |
|
Awesome! As a heads-up: I ended up changing the default for this from true to false (see #1025), since it seems to be causing quite a bit of trouble elsewhere too. Pinging @mitchellwrosen about that, you may need to add |
|
Good to know, that means we won't have to change our configs at all, and things will just magically work :) |
|
Just caught up on this thread, thanks @snoyberg. I definitely didn't realize up front what a nightmare allowing Setup.hs to use local packages would become. |
If I (in a custom snapshot) depend on
entropy, and also depend on a newer version ofunixthan comes with ghc 7.8, the configure fails:To reproduce, download this reproduction and issue
stack build.The text was updated successfully, but these errors were encountered: