-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nix cannot execute Shake's test suite #267
Comments
All builds at http://hydra.cryp.to/project/shake fail as well. I've disabled the CI job for the time being. |
The error is fallout from #252, which means I now reconfigure Shake into a different directory so I can generate documentation. So the relevant bit from the log is:
That's pretty horrid. I guess I need to grab the GHC_PACKAGE_PATH and convert that to a |
Seems like yesodweb/yesod@a7cccf2#diff-7cd4bde7642547b86872a48f8139829eR138 should be able to be applied here as well to translate the variable. |
I've fixed this as part of getting Stack to work, can you try again now @peti? |
The current
|
Yes, the test depends on the cabal tool, can I add that as a run dependency some way? |
Strangely enough,
Then the
in its test suite stanza. |
If I add
|
What do you have as the GHC_PACKAGE_PATH when running Nix packages? Is it accurate? Does it contain a cache of packages? Will it have all the packages required to build Shake? Given cabal is a runtime dependency, I really don't want to add it to the compile time dependency list, and writing my own Setup.hs fills me with horror - it makes everything related to Shake much harder. Any way to hint at it being a runtime dependency via other mechanisms? Nix specific metadata somewhere? |
GHC_PACKAGE_PATH is accurate and refers to a directory that contains the transitive closure of all dependencies listed in the Cabal file. I'm not sure what the distinction between run-time and compile-time means with regard to the test suite. The test suite is run as part of the build, so arguably everything that's a run-time dependency of the test suite is a compile-time dependency of your package. I realize that the complications involved in getting those dependencies declared accurately are unpleasant and that you'd prefer to avoid them, but I don't see a way to accomplish that. If you execute Personally, I would not want my test suite to depend on Maybe you could try to detect the presence of |
Building the test and running it are definitely two different things, although I can see how you might run it as part of the overall build step. I would significantly prefer my test suite to not depend on Cabal, but every other approach has failed on other platforms for other reasons - I just want to generate haddock documentation and then check it is type checks. I might have another go at avoiding Cabal and using My concern with a custom Setup.hs is that it breaks plenty of other things and the API changes every 5 minutes, so the benefit of tests is Nix is probably outweighed by the cost of a custom Setup. I have used custom setups in the past, and vowed never to again. 4 times bitten, 5th time shy. If all else fails, I'll just exclude this test based on the presence/absence of cabal, but then I always worry that my standard tester will accidentally put cabal in the wrong place and I'll omit tests I wanted to run. But that's not the end of the world. TLDR: I'll try and avoid Cabal first. |
Well, you are right, of course. It's just that
Using
The custom-build API is subject to changes, no doubt, but that particular part of the API has been stable for a long time. I wouldn't worry about the stability of your build because of use of the
You could check the presence of an environment variable, say |
I've switched to |
Now it says:
|
Hmm, it looks like it's trying to runhaskell on a literal file called Setup. Any chance Nix created that, and thus GHC's "find Setup.hs or Setup.lhs" logic got bypassed? |
OK, I've made it explicitly ask for |
Now we're back to the same error we had with
Not sure what is going on with
|
I take the path and pass each to cabal in order. I guess cabal prefers the last flag, and GHC prefers the first path entry. I've now reversed it, which might give you more luck. |
(It would be nice if Cabal just obeyed the path like everyone else did :() |
535857e gives the same error as before: no change. What bothers me is the path |
Given a |
According to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#ghc-package-path, the meaning is:
|
I did not know what. Now I just filter out |
|
|
46b7533 succeeds its test suite in Nix. Wow, that was easy!
I find it hard to imagine that this could possibly be intended behavior. And if it is, then it's still a really bad idea. Have you considered reporting this phenomenon as a bug? |
Finally! Thanks for all your help - I owe you a beer. I've raised haskell/filepath#51 (to myself, as it happens) to investigate. I suspect this may meet both platforms guidelines, but if so, it needs explicitly documenting as a difference. |
Is there going to be a new release of |
Shortly, yes, although the fsatrace stuff is currently in flux. I guess my options are to release saying that is unsupported, or wait a while til that clams down. @jacereda - any thoughts/preferences? |
I'll be working on fsatrace and I think I can have something releaseable on Monday. But if you're in a hurry go ahead. |
Not in that much of a hurry - my Friday and weekend are already spoken for so early next week sounds good. |
Just take your time guys, there's no need to hurry. When the new version comes out, please just ping be briefly so that I can update the build expression in Nixpkgs to run the tests. |
Shake's test suite depends on
ghc
being aware of extra packages, which we achieve by setting$GHC_PACKAGE_PATH
. New versions of the test suite, however, run some kind ofcabal configure
, which fails when that environment variable is set: http://hydra.cryp.to/build/942465/nixlog/2/raw.The text was updated successfully, but these errors were encountered: