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