<mark_weaver>"Package management with cabal is the single worst aspect of using Haskell. [...] Comments connected cabal with words like hell, pain, awful, sucks, frustrating, and hideous."
<mark_weaver>'Asked if improvements to package management would make a difference to their future choice of Haskell for a project, 38% said it would be "crucial" and a further 29% said it would be "important".'
<mark_weaver>without -K, the build directory is automatically removed
<mark_weaver>in your install phase, you should be #t after the (for-each ...), to signal success. phase procedures are expected to return a boolean indicating success or failure.
<ewemoa>mark_weaver: thanks for the comments -- i will try the .dir-locals.el idea and thanks for spotting the duplicated git clone -- have been using -K fruitfully when testing, will add it to the write-up
<mark_weaver>also, it's good that you added a 'file-name' field for the git checkout. we should probably add something like that to all of our 'git-fetch' origins.
<mark_weaver>it's good to see that kind of attention to detail :)
<ewemoa>mark_weaver: ah, good to have confirmation of that -- wasn't sure :)
<mark_weaver>ewemoa: I would also recommend you consider building guix from the git checkout and getting in the habit of making changes directly to the git checkout. this takes a modest initial investment in time but is well worth it, IMO, for several reaasons.
<mark_weaver>it means you can contribute your packages to us properly
<mark_weaver>it means you can modify your local copy of guix in arbitrary ways, not just by adding packages, and git helps make it easy to merge our continued upstream work into your local branch.
<mark_weaver>or alternatively, periodically rebasing your local commits on top of our upstream. that's what I do, but it's a matter of preference.
<ewemoa>mark_weaver: yes, it sounds like a good idea to work off of a checkout -- i used to do that but when i tried before, i ran into difficulties which i didn't resolve -- perhaps it's worth trying again
<mark_weaver>I'd be glad to help you work through any problems you might have.
<ewemoa>thanks -- then i may move in that direction :)
<mark_weaver>after you already have guix it's easy because you can use 'guix environment guix' to launch a subshell with everything you need to build guix.
<mark_weaver>just make sure to pass --localstatedir=/var --with-libgcrypt-prefix=$HOME/.guix-profile
<mark_weaver>ngz, alezost: the binary tarball includes /gnu/store/sfw64fin80dhmn160cq71f46v7hfgbfm-guix-0.8.2/share/emacs/site-lisp/guix.el but I don't recommending adding that store directory to your emacs load-path directly.
<ngz>alezost: the problem is that a "locate" on "guix.el" only returns something in the store,
<alezost>mark_weaver: I'll make a patch for that later today
<ngz>On another topic, while I'm at it, I have a PATH problem. I have modified .bashrc to export various guix related environment variables. However, gnome (from Archlinux) apparently cannot find executables (e.g., Emacs) installed with guix.
<crtsyal>mark_weaver yeah that fixed it. I feel a bit foolish now.
<alezost>ngz: I think that's because gnome is running by a systemd service which knows nothing about your .bashrc environment
<ngz>I think so. But I don't know what files it knows about.
<ngz>So if I create a shortcut (e.g. Super+E) for Emacs, it launches host distrib Emacs, not the one from guix.
<alezost>ngz: I know that "systemctl set-environment" may be used to change the systemd env on the fly (also you may use "systemctl show-environment" to find your current env), but I don't know how to make systemd to set environment before it starts services. I think there should be some config file for that.
<alezost>ngz: or maybe there is some "Gnome-special" way to change the env
<mark_weaver>ngz: you should avoid setting environment variables in .bashrc for other reasons. it causes them to be reset in *every* interactive shell, which prevents you from having shells where the environment variables are set in a different way.
<mark_weaver>in particular, the 'guix environment' command spawns a subshell with different environment variable settings. that command won't work properly if you reset your environment variables in .bashrc
<ngz>mark_weaver: I know. But it's the Archlinux way to proceed. .bash_profile consists of a single line: [[ -f ~/.bashrc ]] && . ~/.bashrc
<mark_weaver>ngz: well, that way is incompatible with the 'guix environment' command.
<ngz>So they just blur the differences between the two commands.
<civodul>but they should already be on librenote no?
<civodul>or maybe they're on the other mips machine?
<mark_weaver>civodul: as I recall, you once specifically told me that substitutes must be disabled on hydra build slaves.
<davexunit>ah, 'guix environment' is lovely. I was in my guix dev environment, but I wanted to experiment with libnl bindings for containers, so I just ran 'guix environment --ad-hoc libnl' to add it to the environment.
<mark_weaver>I guess they _were_ on the other mips build slave, but I just ran "guix gc" without arguments on it.
<davexunit>civodul: looking forward a bit, I'm attempting to use libnl for the networking component of the Guix container implementation. I know that adding more dependencies isn't the best thing, so should we make it optional somehow?
<mark_weaver>davexunit: if you use the dynamic FFI to get to it, then it can be optional in the same way that gnutls is optional now.