Regolith installable with Nix

[tartavull]

Hi There,

I've been using Nix and home-manager to install all my packages. I would love to be able to install and configure regolith with Nix. Any advice on where to start contributing to this?

Ignacio

[kgilmer]

Well, Regolith is just a collection of debian packages. I do not have any experience with Nix but if you can configure it to use a PPA (debian repo) and specify a package to install, then Nix should be integratable with Regolith. The Regolith package you'd want to install would be regolith-desktop or one of the variants (in Regolith 1.x).

[ploum]

@tartavull : I’m a bit curious about Nix packaging. On which OS do you use it? Are you mixing Nix packages with other packages?

[MatrixManAtYrService]

You can use Nix on other OSses, but it seems like it would get confusing keeping track of which parts of the OS were tracked by which package manager. NixOS is a distro where everything is managed by Nix--that's where I'd like to install Regolith. Sadly, I'm a just curious user and not yet in a position to be contributing packages that I've authored myself.

These seem relevant, though I can't vouch for either.

• https://reflexivereflection.com/posts/2015-02-28-deb-installation-nixos.html
• https://unix.stackexchange.com/questions/520675/making-a-simple-deb-package-nixos-compatible-mathematicas-wolframscript

Having to puzzle though making making i3 in nixos resemble regolith is what's holding me back from embracing nix. I like regolith, and I'm not sure how long it will take make nix mimic it. The nice thing about Nix (I think) is that once you've achieved the config you want, publishing it as a package is just a matter of submitting the right part of your local config to the nixpkgs github repo, then other users can derive that same config on their machines (that's a bit less collaboration-friction than building and publishing a .deb, which is part of why people like Nix).

If I ever get over it and take the plunge I'll be sure to document it and post a link here, though hopefully somebody who knows either Regolith or Nix better than me will just add a regolith package in before that happens :slightly_smiling_face:

[lontivero]

I would love to have Regolith in nix too. Sadly my situation is the same that MatrixManAtYrService and i don't know how to do it (yet) because i don't know the nix language but i will try and let you know if i have some result.

[cfsmp3]

From experience - using Nix (the package manager) outside NixOS is painful. I personally hated Nix (with a passion) because I used it inside Ubuntu. I got the worst of both worlds.

I did contribute some derivations to Nix, though, so I might be able to do something here.

I suspect though that since regolith is a lot about packaging and nix just uses its own thing, a lot of the work would have to be recreated.

[MatrixManAtYrService]

@cfsmp3 I've had the same thought: re-recreated work. I'm trying to decide if it would merely be recreating work, or if it would also be duplicating the maintenance burden. Like, would changes to the .deb require parallel changes to the Nix instance?

The reason I think it might not be is that it seems you can use nix to generate a .deb (or .rpm) package with nixpkgs. So if the nix representation was "upstream" then you'd bet the bulk of the .deb stuff "for free", and .rpm would come along too. Do you think that's true?

Even so, I recognize that it's a pretty audacious ask--to change which ecosystem is primary vs which is derived--I'm just trying to get my head around it.

[cfsmp3]

The reason I think it might not be is that it seems you can use nix to generate a .deb (or .rpm) package with nixpkgs

I wouldn't create anything for Debian without using Debian :-) They might change tools, format, etc, at any time and we'd be stuck.

On the other hand, packaging things for Nix (at least basic things that don't require a lot of magic) is not too hard and getting them upstream is very fast because they don't care about having a million versions of the same thing; so there's no dependency hell.

If you are interested in doing it, one good first step would be to create derivations for each individual regolith-only components that don't yet exist in nix, and once all those building blocks exist go up in the tree.

[Atemu]

I don't know much about regolith but I do know a lot about NixOS.

"Installing" regolith as a separate desktop (especially one recognised by the login screen) needs a bit more than just a binary in the $PATH. I doubt that'd be possible with home-manager.

Regolith as a NixOS desktopManager should be possible though.

What exactly makes up regolith?
The main "juice" should in the i3 config right? That, you should be able to use just by running regular i3, using it as the config file.
There also seem to be some other components like the settings GUI, drun and so on. All of those should be relatively easily to configure using a NixOS module though.
Perhaps it's even possible without needing privileges and could be done in home-manager as a special i3 config. I'd need a bit more of an overview over the components that make up regolith to comment on that.

I'd also highly recommend opening issues in Nixpkgs and home-manager if you want to see this integrated.

[kgilmer]

Hi @Atemu ,

What exactly makes up regolith?

Regolith is an integration of gnome-flashback and i3-wm. It's based on https://github.com/regolith-linux/i3-gnome-flashback and this shell script which is responsible for starting a Regolith session after user login should give some sense of internal dependencies. I have no knowledge of Nix unfortunately but in terms of installation, it's just "files on a disk" with some added nuance for dconf/gsettings: Debian packages can install dconf "overlays" that apply selectively depending on login session. Regolith has one of these.

[Atemu]

That honestly doesn't sound too complicated. Flashback just requires some files in global /share right?

Custom startup scripts are trivial to support. You could probably even implement this using vanilla NixOS' services.xserver.windowManager.i3.extraSessionCommands.

The "added nuance for dconf/gsettings" is the part I can't quite evaluate. Is this something that requires state changes in the user's home directory?

If anyone is interested in getting deeper into NixOS, creating a NixOS module for this would be a great place to start.

[cgahr]

What's the easiest way to make regolith for nixOS a reality? What can I do to help?

[Atemu]

I'd start by writing a NixOS and/or home-manager module which configures the i3 module's options to use regolith's configs. When that's done, I'd look into getting the gnome-flashback integration working.

[cgahr]

Related: regolith remontoire being added to nixpkgs https://github.com/NixOS/nixpkgs/pull/249141

According to https://regolith-desktop.com/docs/using-regolith/install/ lightdm can be used instead of gdm3 for a more light-weight installation.

[kgilmer]

Hi! Sorry I do not know anything about Nix so wouldn't have any suggestions at the moment. If I were porting Regolith to a new platform, I might consider first (or only?) focusing on the Wayland session, given the state/longevity of the X11 project. Regolith will continue to maintain X11 and Wayland sessions for the near future but I would expect that at some point we put X11 into KTLO mode. Happy to answer any questions about the architecture or implementation of Regolith itself..

I think an initial question I would try to resolve is: will packages be ported 1-1 or some kind of consolidation? (context: Regolith uses the underlying package manager as a big part of configuration mechanism. The presence/absence of a given package causing configuration changes. This provides a consistent and minimal approach to configuration, but there are downsides as well. There are many (small) packages and maybe difficult for those uncomfortable w/ their package manager. As such Regolith relies on some features of the underlying package manager:

1. package manager allows for abstract package definitions that may be satisfied by one or more concrete packages
2. package manager allows to express conflicts to other packages via declaration
3. package manager allows for new packages to replace old packages via declaration
4. probably more that isn't occuring to me atm..)

[cgahr]

Personally, I'd start with i3, simply because I'm using i3 and want to use Reoglith with nixOS ;)

Following your earlier comment, I looked into i3-gnome-flashback first, seems to be straight forward to install using nix, especially with the DESTDIR variable in the makefile. There I'm wondering however, if I change the DESTDIR, i.e install all files under /nix/store/something/usr/..., will I be able to tell the subsequent parts where to find these files?

[kshitijaucharmal]

Hello, I would like to work on this project for GSOC'24. I am starting to work on the Qualification tasks for this project. Can you provide some insight about the exact result expected in this project?

[Atemu]

I'd say the "end goal" would be a services.xserver.desktopManagers.regolith.enable that, when enabled, configures a mostly working-as-intended regolith desktop. Just like services.xserver.desktopManager.gnome.enable does the same for GNOME.

I'm not sure this would be the right sort of thing but note that summer of Nix is a thing; that might be a more appropriate avenue for this.

[kshitijaucharmal]

So making regolith a desktop manager as a package in nix. Another question, should I start with i3 and work my way towards regolith's config or directly try to include regolith as a package?

[Atemu]

No, that's not quite what I said. I said the goal would be a NixOS option. Whether it makes sense to create any regolith packages depends on the technical circumstances and would be done as part as exposing the regolith desktop as an option.

AFAIUI, it's more more of an elaborate default configuration for another package rather than a classical package of software. System configuration is the domain of NixOS, not Nixpkgs, so packaging wouldn't really help anyone on NixOS.

I'd start by configuring the upstream i3 desktop option to be mostly a bare-bones regolith config and then work to making its custom components that it adds on top of i3 (i.e. gnome-flashback) work.

Judging by @kgilmer's comment, the main difficulty you might run into when creating a NixOS option would be that the upstream intended method of installation and configuration could try to encroach on its domain; trying to modify system configuration at runtime which we do not do in NixOS.

[kshitijaucharmal]

Sorry for the confusion. I think I understand now. I'll start by configuring the i3 desktop by a bare bones regolith. Then work on converting all the custom components work, and then convert this into a nixos option, to be installed in the way you provided. Thanks :)