[bug#35812] [PATCH] fix hackage cabal tests

[Robert Vollmert <rob@vllmrt.net>]

Hi Ludo’,

> On 21. May 2019, at 16:48, Ludovic Courtès <ludo@gnu.org> wrote:
> Robert Vollmert <rob@vllmrt.net> skribis:
> 
>> Hackage cabal tests didn’t run independently due to memoization,
>> and test-cabal-6 was failing.
> 
> I don’t think memoization can get in the way here: the argument list is
> used as a key in the memoization hash table.  Thus, if you pass
> different arguments, you get a cache miss and call the underlying
> procedure.
> 
> Or am I missing something?

I agree that memoization of a pure function shouldn’t have such effects,
but my (limited) understanding is that hackage->guix-packages would
cache import results by package name on the assumption that cabal
files for the same package name don’t change between calls. That
observation is consistent with the test behaviour, but I may well be
missing something.

>> From 8b6dac85a9f6c4e851c1a75a4958dff7915fb2f1 Mon Sep 17 00:00:00 2001
>> From: Robert Vollmert <rob@vllmrt.net>
>> Date: Fri, 17 May 2019 10:48:42 +0200
>> Subject: [PATCH] tests: fix cabal tests to test and pass
>> 
>> * guix/import/hackage.scm: export unmemoized import function
>> * tests/hackage.scm: use unmemoized import function to make tests independent
>> * tests/hackage.scm: fix failing test-cabal-6 by providing expected output
> 
> [...]
> 
>> (test-assert "hackage->guix-package test 6"
>> -  (eval-test-with-cabal test-cabal-6
>> -                        #:cabal-environment '(("impl" . "ghc-7.8"))))
>> +  (mock
>> +   ((guix import hackage) hackage-fetch
>> +    (lambda (name-version)
>> +      (call-with-input-string test-cabal-6
>> +        read-cabal)))
>> +   (match (hackage->guix-package-impl "foo")
>> +     (('package
>> +        ('name "ghc-foo")
>> +        ('version "1.0.0")
>> +        ('source
>> +         ('origin
>> +           ('method 'url-fetch)
>> +           ('uri ('string-append
>> +                  "https://hackage.haskell.org/package/foo/foo-"
>> +                  'version
>> +                  ".tar.gz"))
>> +           ('sha256
>> +            ('base32
>> +             (? string? hash)))))
>> +        ('build-system 'haskell-build-system)
>> +        ('inputs
>> +         ('quasiquote
>> +          (("ghc-b" ('unquote 'ghc-b))
>> +           ("ghc-http" ('unquote 'ghc-http))
>> +           ("ghc-mtl" ('unquote 'ghc-mtl)))))
>> +        ('native-inputs
>> +         ('quasiquote
>> +          (("ghc-haskell-gi" ('unquote 'ghc-haskell-gi)))))
>> +        ('home-page "http://test.org")
>> +        ('synopsis (? string?))
>> +        ('description (? string?))
>> +        ('license 'bsd-3))
>> +      #t)
>> +     (x
>> +      (pk 'fail x #f)))))
> 
> So this test needed to be changed as a result of turning off
> memoization?

Precisely. The other tests all expect various cabal fragments
to yield the same package definition, while the extra fragment

custom-setup
  setup-depends: base >= 4.7 && < 5,
                 Cabal >= 1.24,
                 haskell-gi == 0.21.*

in test-cabal-6 causes the extra native input ghc-haskell-gi.
As I understand it, this test failure used to be shadowed
because hackage->guix-packages would just return the successful
parse of the test-cabal-1.

(There’s probably some more elegant way to avoid duplicating
the whole package definition, but I generally prefer a bit of
explicit verbosity in test data.)

Cheers
Rob