Hi,
On Fri, 26 Mar 2021 at 17:21, c4t0 <c...@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
