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

[c4t0 <c4t0@riseup.net>]

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.