Maybe etckeeper fits your use case? It’s specifically built for managing /etc files with version control systems. I can’t say much about it since I’ve never used it, though.

Hi!

First and foremost, if you haven’t had a look at the Guix manual yet, I recommend starting with that; this is usually my first stop when I’m working on anything Guix-related and come across something I’m not sure how to do. For packaging in particular, I would start with the package reference section.

Perhaps you might find example-oriented resources helpful, too. Here are some links that I included in my notes as helpful guides during my first time making a package definition:

• https://jyscao.xyz/guix-packaging.html
• https://guix.gnu.org/en/blog/2018/a-packaging-tutorial-for-guix/
• https://guix.gnu.org/en/cookbook/en/html_node/

In addition to the above, consider browsing the Guix repository which hosts a practically infinite store of examples for you to sift through and learn from.

Depending on what you’re packaging, you might also find it useful to look at the Nixpkgs equivalent (if it exists) which you can draw some similarities to. I don’t often do this though and sometimes it can make things more confusing since it’s not always a 1-1 match, but I want to put it on the table nevertheless.

Lastly - there might be times you’ll encounter confusing errors or maybe you have a question that the above resources can’t really help with: I highly recommend searching through the Guix IRC channel archive (or joining it!). The more experienced bunch of Guix users (and developers too) can often be found there sharing their great wisdoms. I frequent the logs often, which have been so immensely helpful to me that I wrote a script to scrape the archive so I can search through them more easily with grep.

If you mean use both at the same time, you can! If you check out the website for Nix (or Guix, its Lispy cousin), instructions are provided for installing it alongside your current distro as an additional package manager for those who want to use it without reinstalling or using a vm.

I was pretty much finished writing this post until I realized you might be mistaken with how updating packages works - editing the package version field merely changes what Guix thinks the version is, not the actual package version. By modifying the version field, the source code that’s downloaded will change since the download url is conveniently built off the version variable, but the hash - and potentially the build process itself - will also change because of this. You’ll need to additionally update the hash, at the very least.

However, there’s also a comment in the definition stating “Later versions have dependencies on npm packages not yet in Guix”, so unless this comment is outdated, you’ll have to package newer versions of the dependencies too. While I believe that learning Guix packaging has been a very much worthwhile experience, you might want to use something like the flatpak Justin linked if you don’t want to go through the trouble of figuring this out right now, because as far as I can see this will not be as straightforward as just changing a version number.

Of course, I don’t have context on what you read and I didn’t look at the package definition in depth, so in case I’m the mistaken one here or you still want to know how to proceed for future reference, here’s my original post:

The easiest way to do this would probably be to use the command guix package --install-from-file=path/to/file with a file that returns the modified package.

Notably, you’ll want to also include the original define-module expression at the top to pull in necessary code, as well as add an anki at the very bottom which indicates that the file will return the anki definition:

(define-module (gnu packages education)
  ...)

(define-public anki
  ;; modified package here
  ...)

anki

The above method should work just fine, but I’d only recommend it for short-term usage since it doesn’t scale well nor does it take advantage of the declarative-ness of Guix.

Alternatively, if you’re looking for a more long-term solution, I would suggest either creating your own channel or setting a custom load path where you can write whatever extra code to include in your configuration. The former is the most ideal, but the latter is much easier to set up, only requiring tweaking the module name and setting an environment variable.

Personally, a channel is overkill, so what I do is globally set the GUIX_PACKAGE_PATH environment variable to my config location where I’ve defined custom modules, which I can then pull into my Guix Home configuration (including modified packages). Feel free to have a look at my config for reference, although it’s still fairly work-in-progress right now: https://github.com/aurtzy/guix-config

If you haven’t heard of David Wilson (a.k.a. System Crafters), he’s a great resource for learning Guix stuff, and has his own Guix Home configuration that you can check out as well: https://github.com/daviwil/dotfiles/tree/guix-home