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

[c4t0 <c4t0@riseup.net>]

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.