aurtzy

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.

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