directory-1.2.2.0 test suite fails in NixOS

[peti]

The test suite for directory-1.2.2.0 depends on git, but doesn't declare that dependency in the build-tools: stanza. As a result, NixOS will not include the tool in the build environment, leading to a test suite failure: http://hydra.cryp.to/build/640684/log/raw.

[Rufflewind]

AFAIK, build-tools doesn't support git, so this won't work. (Note: it also requires python2.)

I'm not sure what would be the best way to handle this. Maybe there's a way to do this with a custom Setup.hs but I feel that's going out of the way. I'm not familiar with Nix – is there a way to specify extra dependencies outside of the .cabal file?

[Fuuzetsu]

AFAIK, build-tools doesn't support git, so this won't work. (Note: it also requires python2.)

Doesn't cabal just ignore the tool if it can't find it and prints a warning about it? If not then maybe we have to patch that first.

I'm not familiar with Nix – is there a way to specify extra dependencies outside of the .cabal file?

The practice on NixOS or rather the main package repository, nixpkgs, is that Haskell expressions are generated automatically out of the cabal files so we rely on them to state their dependencies. There is a way to work around this on nixpkgs side (or rather in the tool that does the translation) but tickets like this are created in hopes that the package maintainers can fix the issue on their end. So in the end it'll hopefully find its way into the cabal file where we can pick it up.

[peti]

AFAIK, build-tools doesn't support git, so this won't work.

Just use the following snippet as Setup.hs:

module Main ( main ) where

import Distribution.Simple
import Distribution.Simple.Program

main :: IO ()
main = defaultMainWithHooks simpleUserHooks
       { hookedPrograms = [ simpleProgram "git" ]
       }

[Rufflewind]

Doesn't cabal just ignore the tool if it can't find it and prints a warning about it? If not then maybe we have to patch that first.

It seems to just die when that happens.

I would prefer if it just checked if a command named git existed as a fallback, although I'm not sure how that would fit in the grand scheme of things.

[Rufflewind]

Just use the following snippet as Setup.hs:

Cool, thanks! This seems to work.

Is there anything else required besides git and python?

[peti]

It's hard to tell ...now that git has become available, the test suite fails because it tries to access the network:

running tests
Running 1 test suites...
Test suite test: RUNNING...
Cloning into 'dist/testsuite/ghc'...
fatal: unable to access 'https://github.com/ghc/ghc/': Couldn't resolve host 'github.com'
Test suite test: FAIL
Test suite logged to: dist/test/directory-1.2.2.0-test.log
0 of 1 test suites (0 of 1 test cases) passed.

Just for kicks, I tried running out without the network isolation, and then it said:

fatal: unable to access 'https://github.com/ghc/ghc/': SSL certificate problem: unable to get local issuer certificate
Test suite test: FAIL

Basically, accessing the network is a problem in fully automated builds (like we run in NixOS).

[Rufflewind]

How about if I just put the tests behind a flag and leave it disabled by default?

[Fuuzetsu]

We can disable them by default ourselves but the goal is to have the tests run (otherwise they are useless) if possible :)

[peti]

Yes, @Fuuzetsu is right. We can disable the tests in Nixpkgs; you don't have to worry about that.

It would be great, though, if those tests that work locally could be split from those that require network access. Then we could run the local tests in NixOS, but avoid those that access github.com. If those two kinds of tests were in separate binaries, then this would be quite easy to accomplish in Nix.

[peti]

For reference: NixOS/nixpkgs@a4ffd58. Tests are now disabled, and the build succeeds in Nixpkgs.

[Rufflewind]

The reason why it needs network is to download the GHC repo that contains test suite. Without it no tests can be run. (See this issue.)

Perhaps I should just disentangle the test suite and embed it within network?

[peti]

Well, we have a fundamental assumption in our build process that downloading the release tarball is enough to build the package. If directory needs additional code to run the test infrastructure, then IMHO the proper way to deal with that would be to package that code on Hackage and to depend on it. I'm not sure whether that's a realistic route to go at this point; I know nothing about the GHC test framework. I've always used hspec, which worked great for my purposes.

[Rufflewind]

The GHC test suite lives in the source tree of GHC – i.e. it's not an isolated library so I'm not sure how feasible it is to upload it to Hackage (it's not even in Haskell either).

[Rufflewind]

OK, I've embedded the test framework within the package (Rufflewind@59afb58). While python is still needed in build-tools, git is no longer required.

Would you mind checking again on NixOS?

[Rufflewind]

Looks like which is needed too. The changes can be found here: Rufflewind/directory@7233248...06bc5b9

I made a paltry attempt to build it on a NixOS VM and the package seems to work now. If there are any more related problems, feel free to reopen this issue.

[peti]

Will you make a new release with those fixes?

[Rufflewind]

Done: v1.2.2.1.