Hello. I am new to the Guix GNU+Linux distro. And I’m trying to get the latest version of Anki (2.1.65). However, an older version (2.1.16) is what’s there in the Guix channel (which is too old). I’m reading here that a simple edit to the education.scm file (the version var) would fix it. Unfortunately, the education.scm file in a Guix system is readonly. Unless the guix git repo maintainers update the code, my only option is to make a custom module and package to supply a newer version. Though, I don’t know how to do that (I’m a noobie). I just need help on figuring that out. Any help is appreciated.
Edit: Okay, I totally spaced the text “;; Later versions have dependencies on npm packages not yet in Guix.”. So, for anki to be at version 2.1.65, it needs more npm packages. So, no modern anki right now… However, I did get to learn more about Guix packaging! (I just have to use the flatpak ver as one comment suggested)
Have you tried
guix edit anki
? In addition, I’d like to point out that you also need the sha256 checksum of the release to correctly build it.TL;DR: Go to the Anki GitHub repo (or whatever forge Anki uses), fetch the sha256 checksum of release 2.1.65,
guix edit anki
and update the version number and the checksum.For more detailed information, read https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/
guix edit anki
is readonly…
You don’t need to make your own module, you really just need a package definition. This packaging tutorial is a bit old but should still be helpful.
An easier method might be to clone the Guix git repo, edit the package definition in
education.scm
, and use pre-inst-env to install your newer version.But if you’re going to to that, you might as well just submit a patch so others can benefit from the new package. If it’s just a version bump, it might be as simple as bumping the version number in the definition!
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 ananki
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-configIf 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