guix import hackage fails with errors, and failed tests

guix import hackage fails with errors, and failed tests

[c4t0]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]


Hi!

I'm having problems with 'guix import' in my environment:
$guix import hackage -t ghc-events
Syntax error: unexpected token : common (at line 44, column 0)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'ghc-events'

so I cloned guix, and:

guix environment guix --pure --ad-hoc help2man git strace --container
make check TESTS=tests/hackage.scm

(I need to add --container for a problem that I address in another
email, can be ignored)

I found that two tests are failing with similar error:

Syntax error: unexpected token : (ghc-options (-Wall)) (at line 11, column 2)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test mixed layout
location: ./tests/hackage.scm:295
source:
+ (test-assert
+   "hackage->guix-package test mixed layout"
+   (eval-test-with-cabal
+     test-cabal-mixed-layout
+     match-ghc-foo))
actual-value: #f
result: XFAIL

Syntax error: unexpected token : (buildable (False)) (at line 12, column 4)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test flag executable
location: ./tests/hackage.scm:322
source:
+ (test-assert
+   "hackage->guix-package test flag executable"
+   (eval-test-with-cabal
+     test-cabal-flag-executable
+     match-ghc-foo))
actual-value: #f
result: XFAIL

I'm using guix 5f9b28b231e17749d14a1b95ae9cad68d7315a1e on top of and
old ubuntu, with all packages upgraded.

How can I start a debugger?

I tried several variations of:

guile -l scripts/guix
and then
(main '("import" "hackage" "ghc-events"))

with out success.

I'm interested in checking the tests and the package that fails.

COD.


[-- Attachment #2: hackage.log --]
[-- Type: application/octet-stream, Size: 7114 bytes --]


Starting download of /tmp/guix-file.DXOaUI
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.DXOaUI" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 1
location: /home/catriel/guix/git/guix/tests/hackage.scm:192
source:
+ (test-assert
+   "hackage->guix-package test 1"
+   (eval-test-with-cabal test-cabal-1 match-ghc-foo))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.0FktLK
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.0FktLK" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 2
location: /home/catriel/guix/git/guix/tests/hackage.scm:195
source:
+ (test-assert
+   "hackage->guix-package test 2"
+   (eval-test-with-cabal test-cabal-2 match-ghc-foo))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.oFe2VJ
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.oFe2VJ" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 3
location: /home/catriel/guix/git/guix/tests/hackage.scm:198
source:
+ (test-assert
+   "hackage->guix-package test 3"
+   (eval-test-with-cabal
+     test-cabal-3
+     match-ghc-foo
+     #:cabal-environment
+     '(("impl" . "ghc-7.8"))))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.LeWYkH
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.LeWYkH" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 4
location: /home/catriel/guix/git/guix/tests/hackage.scm:202
source:
+ (test-assert
+   "hackage->guix-package test 4"
+   (eval-test-with-cabal
+     test-cabal-4
+     match-ghc-foo
+     #:cabal-environment
+     '(("impl" . "ghc-7.8"))))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.9yIwGG
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.9yIwGG" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 5
location: /home/catriel/guix/git/guix/tests/hackage.scm:206
source:
+ (test-assert
+   "hackage->guix-package test 5"
+   (eval-test-with-cabal
+     test-cabal-5
+     match-ghc-foo
+     #:cabal-environment
+     '(("impl" . "ghc-7.8"))))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.ulh8bJ
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.ulh8bJ" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test 6
location: /home/catriel/guix/git/guix/tests/hackage.scm:237
source:
+ (test-assert
+   "hackage->guix-package test 6"
+   (eval-test-with-cabal
+     test-cabal-6
+     match-ghc-foo-6))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.7B8uFK
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.7B8uFK" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test multiline desc (layout)
location: /home/catriel/guix/git/guix/tests/hackage.scm:255
source:
+ (test-assert
+   "hackage->guix-package test multiline desc (layout)"
+   (eval-test-with-cabal
+     test-cabal-multiline-layout
+     match-ghc-foo))
actual-value: #t
result: PASS


Starting download of /tmp/guix-file.IOHWEK
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.IOHWEK" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test multiline desc (braced)
location: /home/catriel/guix/git/guix/tests/hackage.scm:275
source:
+ (test-assert
+   "hackage->guix-package test multiline desc (braced)"
+   (eval-test-with-cabal
+     test-cabal-multiline-braced
+     match-ghc-foo))
actual-value: #t
result: PASS

Syntax error: unexpected token : (ghc-options (-Wall)) (at line 11, column 2)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test mixed layout
location: /home/catriel/guix/git/guix/tests/hackage.scm:295
source:
+ (test-assert
+   "hackage->guix-package test mixed layout"
+   (eval-test-with-cabal
+     test-cabal-mixed-layout
+     match-ghc-foo))
actual-value: #f
result: XFAIL

Syntax error: unexpected token : (buildable (False)) (at line 12, column 4)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test flag executable
location: /home/catriel/guix/git/guix/tests/hackage.scm:322
source:
+ (test-assert
+   "hackage->guix-package test flag executable"
+   (eval-test-with-cabal
+     test-cabal-flag-executable
+     match-ghc-foo))
actual-value: #f
result: XFAIL


Starting download of /tmp/guix-file.Jz5fyG
From https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz...
In procedure getaddrinfo: Servname not supported for ai_socktype
failed to download "/tmp/guix-file.Jz5fyG" from "https://hackage.haskell.org/package/foo/foo-1.0.0.tar.gz"
test-name: hackage->guix-package test cabal revision
location: /home/catriel/guix/git/guix/tests/hackage.scm:367
source:
+ (test-assert
+   "hackage->guix-package test cabal revision"
+   (eval-test-with-cabal
+     test-cabal-revision
+     match-ghc-foo-revision))
actual-value: #t
result: PASS

test-name: read-cabal test 1
location: /home/catriel/guix/git/guix/tests/hackage.scm:370
source:
+ (test-assert
+   "read-cabal test 1"
+   (match (call-with-input-string
+            test-read-cabal-1
+            read-cabal)
+          ((("name" ("test-me"))
+            ('section
+             'library
+             (('if
+               ('flag "base4point8")
+               (("build-depends" ("base >= 4.8 && < 5")))
+               (('if
+                 ('flag "base4")
+                 (("build-depends" ("base >= 4 && < 4.8")))
+                 (('if
+                   ('flag "base3")
+                   (("build-depends" ("base >= 3 && < 4")))
+                   (("build-depends" ("base < 3"))))))))
+              ('if
+               ('or
+                ('flag "base4point8")
+                ('and ('flag "base4") ('flag "base3")))
+               (("build-depends" ("random")))
+               ())
+              ("build-depends" ("containers"))
+              ("exposed-modules" ("Test.QuickCheck.Exception")))))
+           #t)
+          (x (pk 'fail x #f))))
actual-value: #t
result: PASS

Re: guix import hackage fails with errors, and failed tests

[c4t0]

c4t0 <c4t0@riseup.net> writes:

it appears to be this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743

It's marked in the hackage.scm to expected fail, but the layout problem
with cabal files seems pretty ubiquos. I'll try to look at it, and move
the discussion there.

If anyone can give me some tip to how start debugging the test, I'll
appreciate it, since I'm pretty new in scheme hacking with guile in
guix. I must be overlooking something very obvious.

Thanks.

> Hi!
>
> I'm having problems with 'guix import' in my environment:
> $guix import hackage -t ghc-events
> Syntax error: unexpected token : common (at line 44, column 0)
> Syntax error: unexpected end of input
> guix import: error: failed to download cabal file for package 'ghc-events'
>
> so I cloned guix, and:
>
> guix environment guix --pure --ad-hoc help2man git strace --container
> make check TESTS=tests/hackage.scm
>
> (I need to add --container for a problem that I address in another
> email, can be ignored)
>
> I found that two tests are failing with similar error:
>
> Syntax error: unexpected token : (ghc-options (-Wall)) (at line 11, column 2)
> Syntax error: unexpected end of input
>
> ;;; (fail #f #f)
> test-name: hackage->guix-package test mixed layout
> location: ./tests/hackage.scm:295
> source:
> + (test-assert
> +   "hackage->guix-package test mixed layout"
> +   (eval-test-with-cabal
> +     test-cabal-mixed-layout
> +     match-ghc-foo))
> actual-value: #f
> result: XFAIL
>
> Syntax error: unexpected token : (buildable (False)) (at line 12, column 4)
> Syntax error: unexpected end of input
>
> ;;; (fail #f #f)
> test-name: hackage->guix-package test flag executable
> location: ./tests/hackage.scm:322
> source:
> + (test-assert
> +   "hackage->guix-package test flag executable"
> +   (eval-test-with-cabal
> +     test-cabal-flag-executable
> +     match-ghc-foo))
> actual-value: #f
> result: XFAIL
>
> I'm using guix 5f9b28b231e17749d14a1b95ae9cad68d7315a1e on top of and
> old ubuntu, with all packages upgraded.
>
> How can I start a debugger?
>
> I tried several variations of:
>
> guile -l scripts/guix
> and then
> (main '("import" "hackage" "ghc-events"))
>
> with out success.
>
> I'm interested in checking the tests and the package that fails.
>
> COD.

Re: guix import hackage fails with errors, and failed tests

[zimoun]

Hi,

On Wed, 24 Mar 2021 at 04:19, c4t0 <c4t0@riseup.net> wrote:

> I'm having problems with 'guix import' in my environment:
> $guix import hackage -t ghc-events
> Syntax error: unexpected token : common (at line 44, column 0)
> Syntax error: unexpected end of input
> guix import: error: failed to download cabal file for package 'ghc-events'

Probably because the cabal file is bad formed.  Or better worded,
because the Guix cabal parser fails to parse the line 44 starting by
'common'.
Well, give a look at (guix import cabal).

> so I cloned guix, and:
>
> guix environment guix --pure --ad-hoc help2man git strace --container

Somehow, --container implies --pure. :-)


HTH,
simon

Re: guix import hackage fails with errors, and failed tests

[c4t0]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 24 Mar 2021 at 04:19, c4t0 <c4t0@riseup.net> wrote:
>
>> I'm having problems with 'guix import' in my environment:
>> $guix import hackage -t ghc-events
>> Syntax error: unexpected token : common (at line 44, column 0)
>> Syntax error: unexpected end of input
>> guix import: error: failed to download cabal file for package 'ghc-events'
>
> Probably because the cabal file is bad formed.  Or better worded,
> because the Guix cabal parser fails to parse the line 44 starting by
> 'common'.
> Well, give a look at (guix import cabal).
>

yes! I don't know if is really related with
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743 and is a layout
problem or it doesn't know how to parse 'common'.

watching
https://hackage.haskell.org/package/ghc-events-0.16.0/ghc-events.cabal
I'm inclined to the later.

looking cabal.scm::make-cabal-parser might help when I get my mind
arround it. Fun fact, i'm just begining a course that ends with
parsers...

There is something else that we could try.

running
$cabal format package.cabal

just removes "common default" and put all that config in the other
targets, for instance:

common default
  default-extensions:
    BangPatterns
    NamedFieldPuns
    PatternGuards
    RecordWildCards
  default-language: Haskell2010

executable ghc-events
  import:           default
  main-is:          GhcEvents.hs
  build-depends:    ghc-events, base, containers


is converted to:


executable ghc-events
    main-is: GhcEvents.hs
    default-language: Haskell2010
    default-extensions: BangPatterns NamedFieldPuns PatternGuards
                        RecordWildCards
    build-depends:
        ghc-events -any,
        base -any,
        containers -any


ammong other things.

I think it might be a good idea to run 'cabal format package.cabal' some
how, before parsing. That will give us a consistent format that might
address the #35743 bug also, and remove formatting variance that a
package mantainer may introduce to make things more legible to him.

Also is easiest than propagate a set of default options to other
targets, but I think the best argument is the former.

maybe modify cabal.scm::read-cabal to make a temporary file with the
input port, run 'cabal format tmp-file' and then change the port to use
that temp file?

WDYT?

If it's ok, I'll give it a try, for now touching the parser it's a
little out of my reach.

COD.

Re: guix import hackage fails with errors, and failed tests

[zimoun]

Hi,

On Wed, 24 Mar 2021 at 16:41, c4t0 <c4t0@riseup.net> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

> yes! I don't know if is really related with
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743 and is a layout
> problem or it doesn't know how to parse 'common'.

I have not read carefully the bug report you mention, neither the
parser.  I guess the parser does not know how to parse ’common’.


> running
> $cabal format package.cabal

You can do that that locally.  Well, currently all the importers via
“guix import” should be considered as helpers to ’import’, not as
bullet-proof ’converters’.


> I think it might be a good idea to run 'cabal format package.cabal' some
> how, before parsing. That will give us a consistent format that might
> address the #35743 bug also, and remove formatting variance that a
> package mantainer may introduce to make things more legible to him.

The «somehow» cannot be using Guix.  Otherwise, it means that Guix would
depend partly on Haskell ecosystem.  That’s why there is a Cabal parser
written with Guile.  Somehow. :-)


> Also is easiest than propagate a set of default options to other
> targets, but I think the best argument is the former.
>
> maybe modify cabal.scm::read-cabal to make a temporary file with the
> input port, run 'cabal format tmp-file' and then change the port to use
> that temp file?

The issue with this is that Guix would somehow depend on Haskell.  And
it would not happen: GHC is not bootstrappable, is huge, etc.


> If it's ok, I'll give it a try, for now touching the parser it's a
> little out of my reach.

Well, if your aim is to produce the Guix definition of ghc-dec, you can
try to run your trick locally.  As said, “guix import” are importers and
not converters, which means it helps to produce a Guix package
definition from a <Foo> package definition i.e., it is not a
bullet-proof converting all the cases; cases probably without a clean
<Foo> grammar.

In other words, to resolve the issue you are pointing, the fix is to
improve the Guix parser of cabal, IMHO.  I hope that this does not
prevent you to contribute by adding ghc-events. :-)


Cheers,
simon

Re: guix import hackage fails with errors, and failed tests

[c4t0]

zimoun <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 24 Mar 2021 at 16:41, c4t0 <c4t0@riseup.net> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>> yes! I don't know if is really related with
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743 and is a layout
>> problem or it doesn't know how to parse 'common'.
>
> I have not read carefully the bug report you mention, neither the
> parser.  I guess the parser does not know how to parse ’common’.
>

the bug report is a problem with layout (indentation). Yes you are
right, in this case is a problem with the keyword 'common'.

>
>> running
>> $cabal format package.cabal
>
> You can do that that locally.  Well, currently all the importers via
> “guix import” should be considered as helpers to ’import’, not as
> bullet-proof ’converters’.
>
>
>> I think it might be a good idea to run 'cabal format package.cabal' some
>> how, before parsing. That will give us a consistent format that might
>> address the #35743 bug also, and remove formatting variance that a
>> package mantainer may introduce to make things more legible to him.
>
> The «somehow» cannot be using Guix.  Otherwise, it means that Guix would
> depend partly on Haskell ecosystem.  That’s why there is a Cabal parser
> written with Guile.  Somehow. :-)
>

Oh well, I've made a patch that does something like:

(system* "cabal" "format" cabal-filame)

and it works. It solves the layout and the 'common' keyword problem.

but yes, you'll need to add cabal-install to the environment when
running tests.
it bothers me that I've used 'system*' and not a foreign function, but it
was the easiest to do to see if it works.

it annoys me too that we have to re do work done somewhere else, it's a
similar problem with editor parsers and language servers.

>
>> Also is easiest than propagate a set of default options to other
>> targets, but I think the best argument is the former.
>>
>> maybe modify cabal.scm::read-cabal to make a temporary file with the
>> input port, run 'cabal format tmp-file' and then change the port to use
>> that temp file?
>
> The issue with this is that Guix would somehow depend on Haskell.  And
> it would not happen: GHC is not bootstrappable, is huge, etc.
>

I get the point of bootstrappable guix, and yes GHC is really huge, but
if you're importing a haskell package, doesn't make sense to require the
haskell ecosystem? you'll be having it installed anyways...

I don't see a problem from the user pov, but I agree with you that is
bad to require a haskell package at testing time.

so... maybe a package that leverages the import system *and* the haskell
ecosystem to aid the haskell package mantainers?

what would be a good idea to leverage the other packaging system tools
to import packages to guix with out making guix humongous?

can we have a module with importers that augment the guix 'native' ones
with foreign tools?

in this case would be ideal to have cabal do all the parsing and make
guix talk with, asking the info that it needs to generate the package
def.

>
>> If it's ok, I'll give it a try, for now touching the parser it's a
>> little out of my reach.
>
> Well, if your aim is to produce the Guix definition of ghc-dec, you can
> try to run your trick locally.  As said, “guix import” are importers and
> not converters, which means it helps to produce a Guix package
> definition from a <Foo> package definition i.e., it is not a
> bullet-proof converting all the cases; cases probably without a clean
> <Foo> grammar.
>

ok, I did that.

> In other words, to resolve the issue you are pointing, the fix is to
> improve the Guix parser of cabal, IMHO.

I'll give it a try in the near future, for now I'll do more damage than
good.

Maybe for the time being, reporting a bug for the 'common' keyword
pushing a new test in hackage.scm with a (test-expect-fail 1) and a
comment to the bug report?

> I hope that this does not
> prevent you to contribute by adding ghc-events. :-)
>

it won't XD
I manage to make a ghc-events.scm package with the hacky patch and
installs just fine in my profile.

I just have to check in runtime with a program that uses it and learn
the ropes a little more to push it.

I guess that I'll have to put all the libraries in haskell-xyz.scm and
threadscope (the culprit of this little adventure) in haskell-apps.scm,
right?

>
> Cheers,
> simon

Chau!
COD.

Re: guix import hackage fails with errors, and failed tests

[zimoun]

Hi,

On Thu, 25 Mar 2021 at 16:23, c4t0 <c4t0@riseup.net> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

>> The issue with this is that Guix would somehow depend on Haskell.  And
>> it would not happen: GHC is not bootstrappable, is huge, etc.
>
> I get the point of bootstrappable guix, and yes GHC is really huge, but
> if you're importing a haskell package, doesn't make sense to require the
> haskell ecosystem? you'll be having it installed anyways...
>
> I don't see a problem from the user pov, but I agree with you that is
> bad to require a haskell package at testing time.

Your mean from the Guix user using Haskell point of view where they
already has this huge “guix size cabal-install”.  What about the Guix
users point of view who are not using Haskell?  That’s why Guix does not
depend on per language tools for the importers.  Without speaking that
Guix runs on many architectures other than x86_64.


> so... maybe a package that leverages the import system *and* the haskell
> ecosystem to aid the haskell package mantainers?
>
> what would be a good idea to leverage the other packaging system tools
> to import packages to guix with out making guix humongous?
>
> can we have a module with importers that augment the guix 'native' ones
> with foreign tools?

Well, Guix provides an extension mechanism, see GUIX_EXTENSIONS_PATH.
Maybe it is the entry point for what you would like to have.


>> I hope that this does not
>> prevent you to contribute by adding ghc-events. :-)
>
> it won't XD
> I manage to make a ghc-events.scm package with the hacky patch and
> installs just fine in my profile.

Cool!

> I guess that I'll have to put all the libraries in haskell-xyz.scm and
> threadscope (the culprit of this little adventure) in haskell-apps.scm,
> right?

Yes, I guess.


Cheers,
simon

Re: guix import hackage fails with errors, and failed tests

[c4t0]

Hello!

zimoun <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Thu, 25 Mar 2021 at 16:23, c4t0 <c4t0@riseup.net> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>>> The issue with this is that Guix would somehow depend on Haskell.  And
>>> it would not happen: GHC is not bootstrappable, is huge, etc.
>>
>> I get the point of bootstrappable guix, and yes GHC is really huge, but
>> if you're importing a haskell package, doesn't make sense to require the
>> haskell ecosystem? you'll be having it installed anyways...
>>
>> I don't see a problem from the user pov, but I agree with you that is
>> bad to require a haskell package at testing time.
>
> Your mean from the Guix user using Haskell point of view where they
> already has this huge “guix size cabal-install”.

yes it's big; but mostly ghc

storage                                                           total    self
/gnu/store/wkhglgmlz28kpkd3ky7f3kfjkxmvyb10-ghc-8.6.5             1639.2  1358.0  79.7%
...
/gnu/store/h9lmnjq7ip6fgpxyj3akjybx3dam218d-cabal-install-2.4.0.0  1703.1    10.2   0.6%

I'll have to ammend my self, it's no really that bad at testing time,
the problem is as you correctly said:

> What about the Guix
> users point of view who are not using Haskell?  That’s why Guix does not
> depend on per language tools for the importers.

We can consider the argument backwards. If a user is not using haskell,
is not even packaging software, why make him have import-code at all?

or why shipping autotools when we can do a parser and macro transformers
in guile-scheme, and so on? I'm pushing it to make the point here, don't
get me wrong; it's obvious that we won't be reimplement gcc in guile
ever.

in emacs we have autoloads. Maybe 'guix import hackage ...' should
then, and only then install the necesary dependencies. Or print a
warning that it'll use a scheme parser and that you can have a native
one installing X.

btw, I've made that cabal.scm use a command line utility for the patch,
and it fails with a warning if something is wrong and continues to parse
with the scheme parser. That because it only formats a file. But the
idea is similar, it only uses it when it available. For testing, well,
you should have it to address the bugs that it solves; otherwise you can
do without.

we already do this with cpan: "If Perl is available in the store, then
the ‘corelist’ utility will be used to filter core modules out of the
list of dependencies." quoted from the manual.

it does something really better that I did though, it checks the store:

(define %corelist
  (delay
    (let* ((perl (with-store store
                   (derivation->output-path
                    (package-derivation store (perl-package)))))
           (core (string-append perl "/bin/corelist")))
      (and (access? core X_OK)
           core))))
           
> Without speaking that
> Guix runs on many architectures other than x86_64.
>

the same applies, if is using haskell chances are that it has x86.

The status for arm is not so bad now a days

https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html

otherwise it won't make much sense to use 'guix import hackage' but it
could use the scheme imp.

It's true though that we couldn't do it with FFI, at least not without much of
a hassle.

>
>> so... maybe a package that leverages the import system *and* the haskell
>> ecosystem to aid the haskell package mantainers?
>>
>> what would be a good idea to leverage the other packaging system tools
>> to import packages to guix with out making guix humongous?
>>
>> can we have a module with importers that augment the guix 'native' ones
>> with foreign tools?
>
> Well, Guix provides an extension mechanism, see GUIX_EXTENSIONS_PATH.
> Maybe it is the entry point for what you would like to have.
>

Are you refering to GUIX_PACKAGE_PATH?



Lastly, programmers that know about parsers are a subset of the ones
that can do api plumbering.

It's been almost two years since this bug

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743

this one has a delay of three years until it solved:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23961

and this one, has been 4 years since open with out much progress.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25138

I didn't do a statistical analysis, and it can be other reason -maybe
nobody cares about haskell in guix and they are using nix?- but I think
that these issues don't get fixed bacause we need to modify a parser.

btw I'm not arguing to push my patch, it's rather hacky, but to initiate
a discussion that can address this to the future.
I'm even willing to try to tackle the parser.

Saludos!
COD.

Re: guix import hackage fails with errors, and failed tests

[zimoun]

Hi,

On Fri, 26 Mar 2021 at 17:21, c4t0 <c4t0@riseup.net> wrote:


> We can consider the argument backwards. If a user is not using haskell,
> is not even packaging software, why make him have import-code at all?

Well, you are not comparing apples to apples: Scheme files (~KB) vs
Haskell (~GB)…

> or why shipping autotools when we can do a parser and macro transformers
> in guile-scheme, and so on? I'm pushing it to make the point here, don't
> get me wrong; it's obvious that we won't be reimplement gcc in guile
> ever.

…I get your point but as I said elsewhere, importers are not converters.

> in emacs we have autoloads. Maybe 'guix import hackage ...' should
> then, and only then install the necesary dependencies. Or print a
> warning that it'll use a scheme parser and that you can have a native
> one installing X.

Yeah, that’s an idea.  It makes sense to me.


> we already do this with cpan: "If Perl is available in the store, then
> the ‘corelist’ utility will be used to filter core modules out of the
> list of dependencies." quoted from the manual.

But it does not say for the Else case. ;-)


> it does something really better that I did though, it checks the store:
>
> (define %corelist
>   (delay
>     (let* ((perl (with-store store
>                    (derivation->output-path
>                     (package-derivation store (perl-package)))))
>            (core (string-append perl "/bin/corelist")))
>       (and (access? core X_OK)
>            core))))

Yes and it is cheap to test.

--8<---------------cut here---------------start------------->8---
$ guix gc --list-live | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix gc --list-dead | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix repl
GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> ,use(guix store)
scheme@(guix-user)> (with-store store
                   (derivation->output-path
                    (package-derivation store hello)))
$1 = "/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10"
scheme@(guix-user)> ,q

$ guix gc --list-live | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix gc --list-dead | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...
/gnu/store/2bx5a99d6z3fn1905yjvzqy890kicfqm-hello-2.10.tar.gz.drv
/gnu/store/kql8b2hbsabcmany4m3hfm3wzdiymliy-hello-2.10-guile-builder
/gnu/store/sihk9hiiqhqkckjs4dzl2vdk5dfv2923-hello-2.10.drv
--8<---------------cut here---------------end--------------->8---


>> Well, Guix provides an extension mechanism, see GUIX_EXTENSIONS_PATH.
>> Maybe it is the entry point for what you would like to have.
>
> Are you refering to GUIX_PACKAGE_PATH?

No, really GUIX_EXTENSIONS_PATH. :-)


> It's been almost two years since this bug
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743
>
> this one has a delay of three years until it solved:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23961
>
> and this one, has been 4 years since open with out much progress.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25138
>
> I didn't do a statistical analysis, and it can be other reason -maybe
> nobody cares about haskell in guix and they are using nix?- but I think
> that these issues don't get fixed bacause we need to modify a parser.

Well, maybe it is a good idea to fallback to Cabal thing if it is
already in the store.  It would avoid to reinvent the wheel as you said.
And it would probably fix a lot of corner cases.


> btw I'm not arguing to push my patch, it's rather hacky, but to initiate
> a discussion that can address this to the future.
> I'm even willing to try to tackle the parser.

Discussion and (new) ideas to address (old) issues are always
welcome. :-)


Cheers,
simon