guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: zimoun
Subject: Re: guix import hackage fails with errors, and failed tests
Date: Wed, 24 Mar 2021 22:12:38 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]