Simplify devos

[jorsn]

I'm not really in a position to write the following as I'm not really part of the devos community, but maybe it's an interesting opinion of someone who has toyed with the idea of using devos but currently finds it too complex and thinks it is currently inconsistent with its own claims.

Current Behavior

1. The github About section describes devos as a NixOS framework.
2. The readme says

we should have a community consensus on how to manage a NixOS system.

3. Both is not the case, and devos is probably diverging from both.

First, I claim that

devos is too opinionated and not opinionated enough

e.g. adblocking is a default network feature, starship is in the core profile, or

https://github.com/divnix/devos/blob/9dcc3c17aa474ba2eba7ea5be5c69e417b2c8ebc/profiles/graphical/sway/default.nix#L65-L68

and

https://github.com/divnix/devos/blob/9dcc3c17aa474ba2eba7ea5be5c69e417b2c8ebc/profiles/graphical/games/default.nix#L10

Also, e.g. some xmonad user is probably not buntish enough to use any config but might want another userland than alacritty+dzen2+qutebrowser.

At the same time the profiles/suites don't configure whole desktops like Fedora spins, so that you cannot just say “give me a default lxde desktop”.

You get too specific and inflexible defaults for a framework and are not simply ready-to-goto with some NixOS flavor (my ad-hoc term). Both target people I imagine are missed. I imagine people who want to understand and tweak and people who want to simply use a complete solution.

Second, I think

devos is too complex and complicated

to be remotely understandable by anyone not very familiar with nixpkgs. If something shall be a community standard, it must necessarily be suitable for newcomers. I don't use devos partly because it's too complicated. It tries to be too smart. There is automatic import of directories, spread of similar concepts across many directories, like profiles, suites, externs, users, user profiles and overlays, packages, overrides. It is also not really consistent at this: Why get suites passed to modules while profiles don't (or do they)? How do I compose modules and suites from multiple flakes?

Maybe devos is in the danger of becoming the spacemacs of NixOS.

Possible Solution

I think devos should clarify goals: Shall it

1. be a certain flavor of NixOS with cool stuff to reduce boilerplate for power-users?
2. or be a very smart blackbox SpaceNixOS/Nixbuntu which infers what the user would probably like ahead-of-time, but if the user wants to change one of the default assumptions it gets very hard?
3. or be a structure for NixOS configurations so that as a user I only have to think about what/how to configure and not how to organize it to be sustainable, but I can bend everything as I like easily?
4. solve specific pain points of setting up NixOS (e.g. secrets management)?
5. be rather a template or a library or both?
6. be/do something else?
7. be a combination of these?

(1.) and (2.) cannot be anything like a community consensus on how to manage a NixOS system and (2.) is no framework.
Edit: (2.) would need really thorough documentation to be usable. I didn't find in the docs e.g. how to use profiles or suites.

I'd propose

though I'm not really in a position to propose:

If a community consensus is a goal, look at what the marketing team is doing/maybe coordinate with them a bit.
Indendently, I'd propose number (3.), the vision being that people are not overwhelmed by many config examples but have a more general one.

Therefore I'd suggest profiles/suites some of which are very generic and maybe some of which are very specific like relatively complete example configs.

Similar concepts should be streamlined and only the directories with really have distict meaning be kept:

1. example: (profiles, suites, externs, users, user profiles) could be reduced to regular config attributes (profiles, suites (for convenience), inputs (for flake inputs or nixosModules from flake inputs) and users (not sure how to organize both NixOS and home-manager)) all available in the same way as config attributes. Either everyone of them is enabled by importing, or by an enable switch.
2. example: (overlays, packages, overrides) can be reduced to overlays, and one overlay defined in flake.nix adds the attribute inputs providing packages or overlays form flake inputs.

This would have the nice side effect that profiles, suites and users could simply be exported by the flake as modules and the modules would be usable in configurations not providing specialArgs to nixosSystem.

Things should be rather explicit so that one understands what's going on, at the expense of some repeated patterns. One cannot understand the structure of the config if one doesn't understand how things are imported and composed. Also, for people to understand, a collection of all the smartest technologies (Nix, NixOS, home-manager, depoly-rs, dhall, git-annex, nuclear fusion) is hard to understand and should, in my opinion, not be a prerequisite to using and modifying your OS config. I'd love to have more typed stuff in Nix, and compared to Dhall the typing in NixOS modules feels a bit improvised, but as long as Nixpkgs use Nix lang, are e.g. the gains big enough to justify that people shall learn Dhall?

When people asked me for my home-manager config as an example, I realized that they wouldn't really understand what's going on because I used too much auto-import magic (recursively import dirs, only default.nix if exists or everything otherwise, remove double typing by generating attrsets { ${basename path} = callPackage path {}; ... }. Probably, there is already (more than?) enough magic to start in NixOS modules and Nixpkgs fixed-points and two kins of overrides.

Flakes are fine if the goal is to be a reference not right now but for early adopters or when flakes are stable.

[nrdxp]

Thanks for opening this. Don't worry about not being a part of the community. Ideally, anyone a part of the nix community is part of this one as well. I was going to open up an issue similar to this, because while the goal is a community consensus, I don't feel like we have gotten enough feedback to actually acheive that goal just yet. We can use this thread for anyone to clarify their pain points.

Layout

The directory layout has been a personal pain point for me. I haven't really been perfectly satisfied with it from the beginning, but then, that's why I wanted to encourage feedback like this. Whatever the finally directory structure looks like (and I like your suggestions) it will definitely be a lot simpler than it is now.

Community Profiles

Several of your complaints are coming from the community branch, which is a bit of a misnomer at this point, since there hasn't been a single community contribution to that branch. It's really just some profiles I've used. It definitely needs to be fleshed out, and possibly completely overhauled (possibly namespaced). The point of it was to levarage the experience of the wider community for various concerns. This unfortunately hasn't even started yet.

Toward 1.0

The main focus right now, is to move toward a 1.0 #121 release where we address all the community gripes and reduce the complexity as much as possible. This project has really just been a huge experiment from day one. Some really cool ideas have come from the community, for example #93

I think, if we can continue to get quality contributions like this, we will acheive our goal. I never wanted to do this alone, as I know I am not smart enough to decide what's good for everybody else 😄

Goals

That said, I think, perhaps the name of this issue could be changed, because your complaints seem to target the implementation, not really the goal. The goal is simply stated in the readme. We should have a community consensus.

If it doesn't seem like it yet, it's because it's not. We need more help, and there is also the possibility that this project becomes irrelevant in the future, which is totally fine with me, as long as we can move the larger community toward some kind of consensus. It seems this is an issue virtually every new nix user is facing, and somebody needs to solve it well.

If there is one goal I wish to personally reiterate, it's that we need to reduce the complexity a whole bunch before we get to 1.0, or at least hide it from the user. I won't tag a 1.0 unless and until we reach this goal.

As an aside, I have struggled with what to put in the github about section, so if you have a good suggestion, please do share.

On Documentation

Also, you said you haven't found any docs on suites or profiles? But the README.md is right in the respective directories, and their is also the rendered mdbook guide. Was it that the docs aren't clear enough or have you not seen these yet? In terms of documentation, I'm trying to make that better, and I have a secret project I'll be releasing (hopefully soon) to make that a lot easier.

[blaggacao]

Re: folder magic

I think it is helpful to have some magic here to make everyday usage easier (even at the expense that it is not always that plain and self-documenting).

Once the project matures, I think an even higher level inteeface to "nixos done with flakes" might be extracted into numtide/flake-utils in order to provide an even more generally accepted foundation (not only for devos).

If so, the value added of this project can be a "specific layout with magic" with a roughly consistent use case in mind.

[jorsn]

@nrdxp Thank you very much for your friendly reply which clarifies already that it's the implementation and not the goals that are inconsistent with the readme.

On Documentation

Also, you said you haven't found any docs on suites or profiles? But the README.md is right in the respective directories, and their is also the rendered mdbook guide. Was it that the docs aren't clear enough or have you not seen these yet? In terms of documentation, I'm trying to make that better, and I have a secret project I'll be releasing (hopefully soon) to make that a lot easier.

I found the readmes, and you're right that usage of suites is documented there while usage of profiles isn't. As everything else here seems to be wired together in Nix it seems a bit odd that one should include profiles by path, but this is the case, currently, isn't it? (maybe has to do with #127; note that anonymous modules (not by path) cannot be disabled via disabledModules at the moment: NixOS/nixpkgs#114131) I rather expected some wiring and missed documentation about it.

For documentation of lib functions: Do you know https://github.com/tazjin/nixdoc? It is used by nixpkgs to generate the function doc in the manual. Pandoc somehow misses out the type signature (section subtitle) when converting to html so you probably need the xml tools used in the nixpkgs manual.

[nrdxp]

I didn't know about nixdoc, I was about to reimplement it. Actually I was almost done 😛. Of course, if it fits the bill, I'd rather not suffer from nih.

The profile docs are under the profile section. In general, the docbook guide is rendered from each README.md file in each subdirectory, explaining that directory. That way, you can read the docs directly on github, or from the website.

Also, profiles aren't meant to be general. Although they are meant to be reusable. So for example, the gps coordinates you showed should definitely be moved to a host, as it is machine specific information. But profiles are where the abstraction ends and the idiosyncrasies begin. There is nothing stopping you from having more than 1 xmonad profile, for example. I don't want anyone to have to sacrifice their preffered setup by trying to overgeneralize it. Much better to setup things the way you want, and if someone else wants to offer an alternative config, please do.

I've been thinking about namespacing profiles to make this more clear. So instead of profiles/develop, it could be profiles/nrdxp/develop.

Also, the reason profiles aren't passed into configs while suites are is to encourage the use of profiles from suites, rather than ad hoc profile management, which got a bit out of hand for me pretty quick. The only place you should do this is from a profile itself, to specify a dependency on another profile.

[nrdxp]

Made a slight improvement to profile docs in #139

[jorsn]

Also, profiles aren't meant to be general

Please suggest (or just set if you can) a better title if you see the need.

What's the relation to the NUR, if the profiles are personal settings which are to be shared? Sharing personal packages, modules, overlays etc. overlaps with the purpose of the NUR. I'd see two reasons to keep this and NUR separate:

1. NUR file structure might be incompatible with devos' needs/ideas. One might be that the NUR api is smaller than the flake api.
2. Personal clones of devos might be more for private stuff. But then they are not to be shared and the profiles should be generic.

Benefit of NUR:

1. It is established.
2. It is namespaced by user.
3. It has a global packages search.
4. No PR workflow (workload) for updating your own stuff, but auto updates if the tests succeed (which means, i think, that the repo evaluates).

Being part of NUR could mean that this would be a template both for NUR and a NixOS flake, and users would be encouraged to put their stuff not into a community branch of a central devos repo but into the NUR.

[nrdxp]

Honestly, I've never even tried to use NUR, so I can't answer this question very well. Perhaps someone with more experience on that front can chime in. I didn't realize one could provide NixOS modules in NUR. I guess I figured NUR was just for packages. It is possible that you are right and NUR would be a better solution than community.

As it is now, you can search community packages as well like so nix search "github:nrdxp/devos/community" SEARCHTERM. Users can also easily make a profile that imports whatever they want from NUR.

Off the top of my head, an argument for not using NUR for profiles would be to keep everything in one place, similar to the monorepo philosophy of nixpkgs. Additionally, I'm not sure if NUR can/will ever become a flakes first approach.

[jorsn]

I didn't realize one could provide NixOS modules in NUR.

In principle you can expose everything over the NUR, while there are conventions for packages, NixOS modules, overlays and library functions. Home-modules are not standardized, even if hmModules seems common (issue).

keep everything in one place

Why? In Nixpkgs it's for consistency and maintainability. Profiles aren't meant to be consistent, are they?

Additionally, I'm not sure if NUR can/will ever become a flakes first approach.

There you've got a point, but I'm pretty sure it won't before flakes are officially stable. Also, the relation between NUR and https://github.com/NixOS/flake-registry is not clear to me. A benefit of the NUR is that it only contains commits which passed the central CI tests.

I think it would probably be easy to have a valid flakified NUR repo based on flake-compat. The least intrusive would probably be: Structure devos as we like, and add a nur directory which provides a NUR adapter via flake-compat. I'm not sure whether this is only the default.nix or if the ci.nix is also needed.

[blaggacao]

I feel the urged to ask critically: has the NUR a goal of being forward-compatible in all respect with the flake's decentralized (once evolved) sharing model?

If that is the case, my reasoning is that NUR should be(come) naturally compatible with all things flake, hence devos, by virtue of the (conpletely standardized) flake.nix interface.

I think in the power-relation theater of repositories, flake should be regarded as the "upstream" and devos as well as NUR as "downstreams".

Sure, why not build a bridge for the down"streams" in the meantime? Would have NUR a bridgehead already built?

[nrdxp]

@Jrson, your input has inspired the following: nix-community/NUR#331, which may offer a cleaner interface to NUR for flake users, while also opening up a pathway for exporting some of your ideas from here to NUR.

[jorsn]

I feel the urged to ask critically: has the NUR a goal of being forward-compatible in all respect with the flake's decentralized (once evolved) sharing model?

Let's see how Mic92 reacts in the issue opened by nrdxp and possibly start a discourse thread about this issue later.

[jorsn]

Cross-posting from the NUR issue:

Here is an example of how you can flakify your NUR already somehow: https://github.com/jorsn/nur-packages/tree/flake
Somehow, because it tries to access urls (flake inputs) and therefore doesn't pass the CI checks, at least for non-flake nix + flake-compat + restrict-eval = true.

[blaggacao]

I think namespacing would give some pretty good mileage for the sharing model, inspired by flake-utils/simpleFlake