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: c4t0
Subject: Re: guix import hackage fails with errors, and failed tests
Date: Wed, 24 Mar 2021 16:41:24 -0300

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.



reply via email to

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