Hi, ison writes: > Since this hasn't received any replies I'll give my solution, although I > apologize in advance if this isn't the "best" way to do it. No need to apologize! There are many ways to solve problems, and often I find it very helpful to see the different ways others have solved the same problem. Thank you for taking the time to share your example! > (package > (inherit curl) > (substitute-keyword-arguments (package-arguments curl) > ((#:tests? #f #f) > #f))) That's a great example! Unfortunately, I'm not sure it will work out of the box. I think you would need to write it like this (note the "arguments" field): (package (inherit curl) (arguments (substitute-keyword-arguments (package-arguments curl) ((#:tests? #f #f) #f)))) Furthermore, although that will successfully disable tests for the curl package because it lacks a #:tests? package argument, I don't think it will work in general. For example, suppose you try the same trick for the emacs-dash package, which has the following arguments: --8<---------------cut here---------------start------------->8--- scheme@(guix-user)> ,pp (package-arguments emacs-dash) $12 = (#:tests? #t #:test-command '("./run-tests.sh")) scheme@(guix-user)> (define emacs-dash-no-tests (package (inherit emacs-dash) (arguments (substitute-keyword-arguments (package-arguments emacs-dash) ((#:tests? #f #f) #f))))) scheme@(guix-user)> ,pp (package-arguments emacs-dash-no-tests) $13 = (#:tests? #t #:test-command '("./run-tests.sh")) scheme@(guix-user)> --8<---------------cut here---------------end--------------->8--- The arguments are unchanged. I think this happens because the substitute-keyword-arguments form you've used looks specifically for a #:tests? keyword argument with value #f (the Guile manual explains that the #f pattern will match only #f, in (guile) Pattern Matching), so it doesn't match in the case where #:tests? is given the value #t explicitly. This results in no substitution. My understanding is that you intended to disable the tests. I think you can still accomplish that if you change the (#:tests? #f #f) part to (#:tests? _ #f), like this: (package (inherit curl) (arguments (substitute-keyword-arguments (package-arguments curl) ((#:tests? _ #f) #f)))) Here, the underscore in (#:tests? _ #f) is a variable that will be bound to the existing value of #:tests? (and then ignored). This _will_ match #t, so the substitution will occur even when #:tests? was originally set to #t. > [...] if you save that to a file called my-curl.scm you could install > it to your guix profile with "guix package -f my-curl.scm" Maybe you already know about this, bu one can also use GUIX_PACKAGE_PATH or set up a local channel (i.e., a channel for which the url is simply a path to a local Git repository, such as "/home/marusich/my-guix-channel"). I've found that putting custom package definitions in a single place makes it much easier to manage, especially because then I can install any of the custom packages in a manifest file via "guix package -m my-manifest.scm". Wayne writes: > my follow up question is whether there is (or a plan for) any > support for sharing these derived custom build binaries with other > users Yes! For starters, see (guix) Channels in the manual. Here's an online copy: https://www.gnu.org/software/guix/manual/en/html_node/Channels.html Basically, channels provide an easy way for people to share custom package definitions - but not binaries. It's very nice! Here's a blog post showcasing them in more detail: https://www.gnu.org/software/guix/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/ > thus basically are there any plans for sharing custom package > definition binaries, perhaps even peer-to-peer? i thought that i had > read something about this on this list but cannot find it currently in > the archives. The task of sharing package definitions is orthogonal to the task of sharing pre-built binaries (called "substitutes" in the Guix world). Sharing package definitions is easy to do now, in a decentralized fashion, thanks to channels and the distributed nature of Git. Sharing substitutes is also possible, but less practical. To start with, you can manually ship around binaries with "guix copy" or "guix archive". And anyone (with root access) can publish substitutes on a network for others to use with the "--substitute-urls" build option simply by invoking "guix publish". You can even set up a build farm like the one running at berlin.guixsd.org if you want. For details on how to do that, see the Guix maintenance repository here: https://savannah.gnu.org/git/?group=guix However, getting people to trust your Guix server's key, providing the substitutes with high availability, and continuously building all the packages is a non-trivial task. Ultimately, it still feels pretty centralized. In the future, we hope people will be interested in contributing to and using a more distributed solution. For example, integration with something like IPFS or Gnunet would be great! But we need help from you and others to make it a reality. For more information, you can check the email lists. I found a few likely results via the following searches: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=ipfs&submit=Search%21&idxname=guix-devel&max=20&result=normal&sort=score https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=gnunet+publish&submit=Search%21&idxname=guix-devel&max=20&result=normal&sort=score If you're interested in helping out or know people who might be interested, please let us know. Happy hacking, -- Chris