Guix community projects: request for info, wishes, brainstorming

Are there any active and maintained guix community projects besides those providing scientific computing packages? Apart from:

There’s a few things I find myself wishing for in guix:

  • per-project environments with guix services
  • declarative hardware configuration
    nixos-hardware
    a lot of nix users express desire to switch to guix but are hesitant because of already existing nix projects and the relative size of the community and a lot of little “quality-of-life” issues with guix
    proprietary drives and firmware are one of those quality of life issues. not including nonfree software in guix itself is fine with me since nonguix fills in the gap, but it certainly could be much easier for the user.
    declarative records of hardware and utilities to add their requirements to operating-system
    (operating-system-for lenovo:thinkpad-intel
     (operating-system ...)))

The records approach to guix packages, home-environment, and operating-system would seem like it would work well for declaring hardware.

I’ve starting fiddling around with an approach like this for my own system configurations:

(define-record-type* <hardware> hardware
  make-hardware
  hardware?
  this-hardware
  (name hardware-name)
  (components hardware-components
   (default '()))
  (firmware hardware-firmware
   (default '()))
  (initrd hardware-initrd
   (default '()))
  (initrd-modules hardware-initrd-modules
   (default '()))
  (packages hardware-packages
   (default '())))
;; components does nothing right now
(define thinkpad
  (hardware
   (name "thinkpad")
   (components intel-components)
   (initrd intel-initrd)
   (initrd-modules intel-gpu-initrd-modules)
   (firmware intel-firmware)
   (packages intel-gpu-packages)))

(define my-os
  (operating-system
    (host-name "my-host")
    ;; Allow resolution of '.local' host names with mDNS.
    (name-service-switch %mdns-host-lookup-nss)
    (initrd
     (hardware-initrd thinkpad))
    (initrd-modules
     (append (hardware-initrd-modules thinkpad)
             %base-initrd-modules))
    (firmware
     (hardware-firmware thinkpad))
    (kernel linux)
    (kernel-arguments
     (append %default-kernel-arguments
             (list "i915.enable_guc=2")))
    (bootloader
     (bootloader-configuration
      (bootloader grub-efi-bootloader)
      (targets '("/boot/efi"))))
    (file-systems %base-file-systems)
    (packages
     (append (hardware-packages thinkpad)
             (cons* gvfs ;; for user mounts
                    nss-certs ;; for HTTPS access
                    %base-packages)))
    (services
     (append thinkpad-system-services
             (list (udev-rules-service 'backlight light))
             (modify-services %desktop-services
               (network-manager-service-type
                config => (network-manager-configuration
                           (inherit config)
                           (dns "dnsmasq"))))))))
  • guix emacs kit and channel
    emacs-overlay
    nix-doom-emacs
    nix-doom-emacs reports being broken due to divergence in package sets and missing package locking mechanism. It seems like something guix would be able to solve with its own emacs “kit”. crafted-emacs would seem like it could be a starting point. I’ve seen on the forums here and here requests for guix packaging for emacs packages.
5 Likes

I like the guix-hardware idea. It would be very convenient to have a common collection of optimized hardware configurations. We can create a dedicated channel for that, or maybe incorporate it into nonguix (since configurations with non-free components cannot be accepted into the main guix channel).

Regarding environments with guix services, I think you can already do that with either guix system container or guix home container or maybe even with regular guix shell. However, can’t say for sure, since I haven’t tried that myself.

As for emacs, a lot of related work has been done in the rde project, since emacs is an important part of it.
There is also an emacs channel with automatically generated packages.

And my addition to the list of guix projects would be:

This is what came to my mind, but you can probably find a lot more interesting things on other guix channels.

3 Likes

I would like to see a nice community wiki, since at the moment a lot of useful information is scattered in different places, and not all information can be added to the official manual and the cookbook.

I also don’t really like the current graphical installer, I would like to write a new one, and if we go further, it can also be a whole graphical interface for guix, more suitable for beginners.

Improving the search via toys and possibly adding it to the official guix website also would be cool.

Also improving channels workflow and making more automation in writing and updating packages.
I’ve seen some interesting ideas on this topic in rde, as well as in main guix development discussions.

1 Like

I think @daviwil or maybe someone else already started working on a new graphical installer :thinking: I agree, it would be great to have. Imo Nix received its current level of interest only after introducing the graphical installer. As an example, I also ended up trying Nix (and later Guix) because of it.

Do you have any pointers/links where I could find those discussions?

I am a Guix newbie and two wishes occur to me. Posting separately

Are there any sites where you can look at recipes to run software in FHS emulation? It took me a while to get SiYuan’s AppImage working under Guix, and I think it would be valuable to be able to collect these incantations somewhere:

guix shell --container --network --emulate-fhs --development ungoogled-chromium libgccjit nss-certs hicolor-icon-theme xdg-utils flatpak-xdg-utils nautilus --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY --preserve='^DBUS_' --expose=/var/run/dbus --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri --expose=/run/user/1000 --share=/home/alvar/NoSync/SiYuan=/home/alvar/SiYuan --share=/home/alvar/.config/siyuan -- ./siyuan-2.12.8-linux.AppImage --appimage-extract-and-run 

Is guix doing the most approachable naming it could do? From my bottomless ignorance, the names of the default profiles bear a lot of responsibility on the prevailing confusion regarding profile activations:

  1. $HOME/.guix-profile is not very informative. It might even be confusing because it’s not the profile that hosts the guix executable (if I got it right). I propose e.g. .[guix-]default-pkgs[-profile] or .guixprof-default or guix-userpkgs. I am sure seasoned users will find even better names.
  2. $HOME/.config/guix/current. Well: it will be current if I activate it. As will the previous one. But, again if I get it right, this does not describe the (default) intent of this profile: to hold the guix executable that is doing the fetching (and the package list?). So why not something along the lines .guix-cli-[profile] or .guixprof-guixcli or guix-usercli. Regardless how good these are, I am sure we can collectively come up with a better name than current.

Naming is hard, but it is important. I am seeing far too longish Stackoverflow explanations of what is going on with multiple user profiles, and, as far as I can tell, the guix profile layering and the bash arcana of where to source stuff is only part of the problem.

PS. I might be so confused that these proposals do not make any sense at all, but I guess that would be even more evidence that something has to be done about the naming of the default profiles.

1 Like

This may not be exactly what you asked, but this is what interested me personally. This is rde main dev note:

Also, it looks like he is going to cook something interesting. Most likely something similar to nix flakes.

As for the other links, things from official mailing lists are easy to find. For example this or that .But there was something else in the chats I read. I haven’t searched them yet. I’ll probably add it later.

How about a Cockpit module for the installer and modules to manage system and home-service generations?