A few things:
First, I want to be clear that I’m not trying to hijack this Nix thread into being a Guix thread. I brought it up originally because OP was asking a broad question about what kinds of challenges might arise for adding more comprehensive Nix support. Guix and Nix are very similar so I believe that my experiences are relevant to that question, but I also believe that “this is technically Guix not Nix” is an important caveat. They share the same core engine and design, but the stuff built on top of that is completely different. However, since that time there have been a couple of Guix-specific posts. I’m replying here because that’s where the posts are, but I would be supportive of splitting these posts into a separate Guix-specific thread.
It’s not on github but it is a git repository. I just want to make sure that is clear because I’ve run into some people (including professional developers) who are under the impression that git is a github-specific tool. The mistake is understandable because github is such a dominant hoster and the names are similar, but you can clone the sourcehut repository just as easily as a github repository. I do not believe that hosting on sourcehut should be a significant barrier for anyone to use, modify, share, etc the code.
Just for awareness, development is slower now than it was before in part because I recently returned to full-time work. This not only means I have less time to work on the project but also exposed some deficiencies in my workflow. For example, I recently updated my Guix VM and this included an update to the linux-libre package definition. This means that I can’t fully test any new code until I finish re-building linux-libre with the configuration and patches provided in qubes-linux-kernel. I won’t leave my computer turned on overnight for reasons, and it takes more than a couple hours for my machine to build the kernel, so it’s been challenging to work on the project this past week. I am in the process of improving my workflow so that these delays occur less frequently and less severely.
However, that is not the only factor causing the project to move slowly. I am also working on some more academically-oriented things. This will eventually converge with my work integrating Guix and QubesOS, but both of these domains are relatively new to me so there is a learning curve. I am also extremely dissatisfied with the way I have gone about the work until now. It’s basically just been “write a package definition that uses the pre-existing build system, see if tests pass and some basic functionality works, and assume all is good”. For a couple of smaller repositories I have read large portions of the source code for anything obviously problematic, but I wouldn’t say that I actually understand how these systems work or how they are related to each other. Assuming that things are fine because they look like they work when I try random things on my machine, without actually understanding why they work, makes me feel nauseous.
Addressing this deficiency is one of the ways in which my academic work and project work will eventually converge. I am aware that there have been historical efforts to create software system descriptions (UML diagrams come to mind) and automatically analyze project structure (I remember seeing at least one paper that analyzes coupling between modules by counting cross-module references on the syntactic level). However, I do not know what the state of the art is and I’ve never actually used these tools personally. I am desperately hoping that I don’t have to do anything novel in order to create a process for understanding a code base.
I’m happy to collaborate with anyone working on Guix/QubesOS integration or Nix/QubesOS integration, whether that means collectively contributing to a central repository or working on separate code bases in parallel. In particular, if there is parallel work on Guix and Nix then some amount of cross-project alignment will probably simplify upstream integration, if any changes to the QubesOS code base need to be made.