unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: c4t0 <c4t0@riseup.net>, guix-devel@gnu.org
Subject: Re: guix import hackage fails with errors, and failed tests
Date: Fri, 26 Mar 2021 23:37:37 +0100	[thread overview]
Message-ID: <8635wha6dq.fsf@gmail.com> (raw)
In-Reply-To: <871rc1u0n4.fsf@riseup.net>

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	other threads:[~2021-03-26 22:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 22:54 guix import hackage fails with errors, and failed tests c4t0
2021-03-24 15:13 ` c4t0
2021-03-24 16:58 ` zimoun
2021-03-24 19:41   ` c4t0
2021-03-24 21:12     ` zimoun
2021-03-25 19:23       ` c4t0
2021-03-26  4:37         ` zimoun
2021-03-26 20:21           ` c4t0
2021-03-26 22:37             ` zimoun [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8635wha6dq.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=c4t0@riseup.net \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).