> Big fan of Guix, though I've only tested it in VMs, via Vagrant[1], for lack of disposable hardware.
Slightly off-topic but this is why I really enjoy NixOS currently, and I'm assuming you can have a similar setup with Guix as the principles seems to be the same more or less, but different implementation.
So the first time I tried Nix I did it in VMs as well. Found it worked out great for me, so I just copied all my configuration files to my laptop after installing NixOS, and now I had a identical copy running both on my desktop in VM and on my laptop "on metal". Great onboarding setup that doesn't waste anyone's time by having to do everything twice, and you get to play around with something you can keep afterwards.
Modelling a desktop OS after reproducible builds is just so nice. Wanna try out a new desktop manager? Just install it, change everything and when you want to go back, simply rollback and everything is back to normal.
Will it avoid the following issues? Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall? How will it roll back the app launcher icons, which is shared by all DEs? Each DE inserts stuff like system monitor, settings etc. Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro? Firefox by itself can disable/remove that extension too. If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
I'm no expert but I'll try my best to answer your questions.
> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall?
Yes
> How will it roll back the app launcher icons, which is shared by all DEs?
If they are shared, they won't be rollbacked as they are used by other DEs.
> Each DE inserts stuff like system monitor, settings etc.
Yes?
> Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro?
Possibly, as long as the install is proper, it'll rollback everything it did to install it.
> If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
No, PPA is for Ubuntu so it's not relevant here. You'd install Python from NixPKGs, and each tool would declare which version it needs, and you'll have all versions installed locally and each program pointed to the version they need. If you need a different version for a local project, just that local project will use that version.
Overall, I'm mainly using AwesomeWM as my window manager. But some weeks/months ago, I wanted to try the full KDE setup. First I tried this on my Arch setup (big mistake) and I still have stray files and things from KDE that I can't seem to figure out how to remove when I wanted to go back.
But, did the same thing on NixOS (from AwesomeWM -> KDE -> AwesomeWM) and I had nothing left from KDE when I went back, as I rolled back the entire system to before it even knew about KDE. Pleasure to try out new DE/WMs now.
> Will it know if it should keep/delete/regenerate file manager indexes for each DE for install or uninstall?
No
> How will it roll back the app launcher icons, which is shared by all DEs? Each DE inserts stuff like system monitor, settings etc.
Application resources like .desktop files and icons are aggregated into _profiles_ via symlinking from the packages, and each state your profile has ever been in is stored as a _generation_. For example:
Guix rolls back application icons the same way it rolls back the applications: your Guix profile's symlink gets rolled back to an earlier generation.
When a desktop environment picks up on that change will depend on how it watches its XDG paths and updates its caches. Afaik Guix (and Nix) don't currently do anything to manage the state of those caches, but logging out and logging back in will suffice. On Plasma, I sometimes run `kbuildsycoca5 --noincremental` to manually refresh my icon and .desktop definition caches.
> Will it be possible to install/remove Firefox integration with KDE and Gnome, which is currently packaged by distro?
WebExtensions and native messaging hosts are packaged in Guix. I wouldn't install them with Guix for use by your base system's browser package, even though that will most likely work. Instead, I'd tell Guix to install both, or to install a browser configured to use whatever extensions.
If you install a browser via Guix, it will not see the extensions that your base system has installed into /usr/share or wherever.
I'm not sure if Guix currently has a package for Plasma's browser integration, but Nix does. In that case, by default it happens to be off, but it is easy to toggle. Whether that integration is enabled is considered a property of your Firefox package, but switching to a new Firefox package where you've changed that option (and perhaps others) doesn't require rebuilding Firefox. So in a word, yes, I think it does solve that problem.
> Firefox by itself can disable/remove that extension too.
This happens at the level of configuration files in your home directory, stuff under `~/.mozilla/firefox/...`. Managing such files is not part of Guix package installation or removal, so Guix won't affect that functionality one way or the other. (There are optional Guix-based tools that you can use to manage such files if you choose, though.)
> If the OS needs Python, can we upgrade Python via PPA so that OS won't use an untested Python?
It's not clear to me what it means for an OS to need Python in this context.
If you're using Guix on a ‘foreign distro’, Python installations managed by Guix will ignore all of the base system's Python packages, and the base distro will pull in its own copies of Python and Python libraries to satisfy the dependencies of its packages according to its own package management system. Guix makes no difference here.
If you're asking about GuixSD, the Guix-based operating system, the OS itself doesn't need you to supply anything external to it— there is no installable package or service in GuixSD that depends on Python which will look for and pick up whatever `python` executable it finds on the PATH. Packages and services that need Python come bundled with their own Python environments, which are fixed as part of the definition of the package or service.
If you're talking about GuixSD and by ‘the OS needs Python’, you mean ‘I want a Python installation and environment to be available to all users system-wide so that anyone can invoke it at the command line with `python` and write scripts that use it when invoked with a `#!/usr/bin/env python` shebang’: yes, it is easy to install a copy of Python which is newer or otherwise different from those included in the default package collection.
If the most recent version of a given package included with Guix is not recent enough for you, you probably don't need to resort to adding an entire third-party package repository to install a more recent one on your system. However, Guix does support third-party package repositories and if one provided a version of Python that you liked, you could install it system-wide.
Its usability by non-specialists can be improved (and is, release by release) but the concept is very promising for reproducible systems.
[1]: https://github.com/OverkillGuy/jibyconf/blob/master/GUIXSD_V...