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: Fri, 26 Mar 2021 23:37:37 +0100

Hi,

On Fri, 26 Mar 2021 at 17:21, c4t0 <c4t0@riseup.net> wrote:


> 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?

Well, you are not comparing apples to apples: Scheme files (~KB) vs
Haskell (~GB)…

> 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.

…I get your point but as I said elsewhere, importers are not converters.

> 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.

Yeah, that’s an idea.  It makes sense to me.


> 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.

But it does not say for the Else case. ;-)


> 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))))

Yes and it is cheap to test.

--8<---------------cut here---------------start------------->8---
$ guix gc --list-live | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix gc --list-dead | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix repl
GNU Guile 3.0.5
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> ,use(guix store)
scheme@(guix-user)> (with-store store
                   (derivation->output-path
                    (package-derivation store hello)))
$1 = "/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10"
scheme@(guix-user)> ,q

$ guix gc --list-live | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...

$ guix gc --list-dead | grep '\-hello-'
finding garbage collector roots...
determining live/dead paths...
/gnu/store/2bx5a99d6z3fn1905yjvzqy890kicfqm-hello-2.10.tar.gz.drv
/gnu/store/kql8b2hbsabcmany4m3hfm3wzdiymliy-hello-2.10-guile-builder
/gnu/store/sihk9hiiqhqkckjs4dzl2vdk5dfv2923-hello-2.10.drv
--8<---------------cut here---------------end--------------->8---


>> 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?

No, really GUIX_EXTENSIONS_PATH. :-)


> 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.

Well, maybe it is a good idea to fallback to Cabal thing if it is
already in the store.  It would avoid to reinvent the wheel as you said.
And it would probably fix a lot of corner cases.


> 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.

Discussion and (new) ideas to address (old) issues are always
welcome. :-)


Cheers,
simon



reply via email to

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