Comparison to `divnix/std` & `divnix/hive`

[fhilgers]

I recently stumbled upon both divnix/std and divnix/digga and wondered how these two nix "frameworks" differ.

[blaggacao]

Probably the best answer can be found in: https://github.com/divnix/hive

I might still port over some ideas with regard to rakeLeaves.

At this point, it's a bit of a hard shot, but in the future, I'd recommend with going with something like divnix/hive or even make a PR for your user in divnix/hive...

[luxus]

imho, at the moment you still need a deep knowledge of nix to understand the differences or even the benefits of digga or std. it's really sad :( i wish someone with a deep knowledge and good presentation would create a short video series with the why and practical examples that are easy to understand. i wouldn't say i'm a novice in nix, but std is really hard to understand :(

[nrdxp]

@luxus, I've got a blog post incoming "soonish" that will hopefully be helpful. I could probably do some videos at some point too, if I ever have time :sweat:

The docs also still need some love, I've been contemplating a complete overhaul of the docs recently, but who has time for that :sweat_smile:

But hopefully we can get there, incrementally.

[luxus]

Many of the explanations are way to abstract.. the std docs sometimes sounds like magic voodoo.. but I'm not here to criticize.. I couldn't do it better :(

[blaggacao]

Actually, a recent addition, The Standard Book, strikes a good middle ground for audiences who are familiar with flakes.

https://std.divnix.com/tutorials/walk-in-the-park.html

[blaggacao]

With a little love, priority and help, we'll eventually get there: https://github.com/divnix/std/issues/209

[blaggacao]

Wow! https://github.com/RaubJo/hive

Thanks @RaubJo

[luxus]

wow thats great. i didn't know about the videos https://github.com/RaubJo/hive#standard-videos

[blaggacao]

I also brushed over the Readme real quick ("low hanging fruits"): https://github.com/divnix/std#readme

[Lord-Valen]

https://discourse.nixos.org/t/hello-std-the-nix-flake-framework-for-perfectionists-with-deadlines/18831/49?u=lord-valen

[jorsn]

Thanks for all your work on those projects, and for improving the documentation of each of them on its own!

However, I think there is really some value in an actual comparison, to tell what is special about this particular project: Currently, I have to understand first what FU, FU+, digga, std, hive, flake.parts, etc. are on their own, before I have any clue about their relation, and whether something supersedes the other, or whether this is simply yet another variation of organising your nix files. Each has their own naming and conventions...

Since I started my PhD, I don't have much time for playing Nix any more, but rather only for using it.

Therefore, I would like to see a simple, concise, precise and complete contribution statement everywhere, as found in every good scientific paper. This has improved a lot for digga and std (or I found it late), but still, there is room for improvement. E.g., the std README could be a bit more concrete and technical, and less advertising. The comparison (literature review, in a paper) provides the context to understand the contribution and thus justifies its relevance and novelty. Is this currently restricted to the recommendation to use std when fed up with digga?

So, why do we need std if we have digga? Is it a generalization that will supersede digga when stable enough? Is it mainly another opinion on organizing your nix files? Why should I get fed up with digga? Where to invest my time in, now? Will digga be a dead horse, soon?

Also, how do flake.parts and digga compare?

[nrdxp]

@jorsn, I can try to at least address your concerns from a high level. We are nearing the first stable 1.0 release of Standard, and a major part of that is bearing down on the documentation and making sure everything is as sensible as possible. We want people to use it for production grade code-bases, so we need to make sure we can brush this up and professionalise it as much as possible.

tl;dr is that once we hit 1.0 we should have a much clearer track on what Standard is and how to use it. As far as a comparison with digga, I can say the two serve different segments. Digga is more for managing your "pets" while Standard is all about managing your "cattle" for production workloads.

That is, digga is useful for those familiar with Nix, want to use NixOS personally and enjoy using the module system. Standard, in contrast, is trying to bring the power of Nix to the mainstream by helping to manage the SDLC more effectively with Nix's superpowers, while trying to stay out of the way as much as possible. The goal is to minimize the pain of onboarding to Nix and bring as much benefit as quickly as possible. One example of this effort is the recent work on divnix/std-action.

Standard abandons common Nix idioms like the module system & overlays (although you can still use them if you really want to, it's not encouraged or documented), and tries to make make the code simpler and hopefully more explicit so new-comers or those just passing over may stand a chance at understanding.

Also, it doesn't try to take over the world with Nix but tries to keep laser focused on where it is strongest (building and running artifacts reproducibly), while leaving open the possibility to use other tools for what they are good for.

Digga is more for personal use on your develop machine. Standard isn't really optimized for this use-case, its more for building/running CI jobs, publishing artifacts (OCI images), creating devshells and even offering those envs in their own dedicated containers. While I have started using Standard for my own system to experiment, I wouldn't necessarily recommend that, as there isn't even a proper type for NixOS systems yet. Not that there won't be in the future necessarily, just that Standard's main focus right now is integrating with other tooling (OCI, etc) to bring the benefits of Nix to the SDLC in a (hopefully) friendly, additive way.

I also have a blog post to go into a bit more detail if you'd like: https://blog.nrd.sh/blog/std/

One last thing I'll say is that Digga is still maintained, but isn't really recieving as much attention as Standard atm. Perhaps when things settle down and we get out a 1.0 we can circle back and formulate a plan for Digga moving forward though. I'd still say its useful and we'll try to fix issues if they come up, but I can't really compare it to flake-parts as I haven't used it much yet personally.

[blaggacao]

Come on, you all know me. I'm known to be bad at this. :smile:

But I'm trying to address more and more of the open questions as we aim for 1.0 in std. For example over here: https://github.com/divnix/std/blob/architecture-and-roadmap/ARCHITECTURE.md

And yes! The contribution / comparision section to related technology, both inside and outside the Nix ecosystem is still missing in that doc (or what that doc will become, eventually). It's on a draft PR, but may already either help clarify some or confuse even more.

Now, to make matters worse, in order to sharpen its profile and focus on a narrow value proposition, std had to outfactor divnix/paisano which is a nix code organization "framework" on which std and divnix/hive are ultimately built on. paisano compares with flake.parts, a little bit with digga (it has one importer but no exporter) and only indirectly supersedes FUP & FUP+ as flake utilities (it's scope is much expanded and its organization principles are much more powerful and flexible).

It's at least conceivable that divnix/paisano's importer may find adoption in the context of digga which has been criticized as too opinionated and I think one can find a very good & similar folder structure by making use of the core principles of divnix/paisano (that then occasionally also serve you at work when you need to cover the SDLC via Standard).

Now if that ended up making everybody dizzy and seeing stars, enjoy the naming scheme over at divnix/hive for a full dose of confusion hypnosis. Jokes aside, it's WIP and I guess we slowly put things into their places for use case XY. Hope that was at least some helpful. You'll tell me :mage:

[luxus]

thanks for all your posts. what still confuses me, can I not use std for my pets? if std is able to cover a cattle, why is there a need for digga? because pets needs more individual love?

what I hope to see with std is like having very small lego blocks that I can add together to build a 1 family house with some small neighbours or a office building complex. so for the office building standard plays a big role, changes that can be role out to all workspaces at ones.. Is std not good enough to create fancy lego blocks to add configurations of Kde or WMs?

[blaggacao]

Let me compensate for the buffoonery of my previous post.

So as per anticipation of v1, the Standard architecture will look (and be explained & documented) somewhat like this:

• divnix/paisano: the importer, spaghetti killer * and code organizer
• A "complete enough" collection of Block Types that type ** outputs along the Software Delivery Lifecycle (SDLC)
• A "complete enough" collection of Cells and Blocks with utilities *** covering the SDLC

* kills spaghetti through a rigid high-level inferface and the promotion of internal code boundaries

** types outputs beyond the limiting built-in nix flake output schema; implements traits on these types, called "actions". E.g. container type can be published

*** productivity helpers around drv-parts (?), dream2nix, numtide/devshell, etc

That holds a couple of implications:

• Standard is a collection of functionality made-to-measure for the SDLC
• The Paisano concepts (code organization, blocktype & cells) can be adopted to other use cases.
• One such example would be NixOS. divnix/hive is an early attempt and still uses std instead of paisano.

And with regard to digga:

• digga is a specific code organization framework for NixOS not made out of small building blocks. The reason people may be fed up.
• A digga-like file organization could be implemented with Paisano + cells and block types as the smaller building blocks. The reason people may be less fed up.
• Adopters of such an evolution of digga will have a strategic benefit. Using paisano under the hood, they learn to organize their home environment in the same way as they could later organize the SDLC at their work place. Instead of using the likes of digga v2, at work, they would switch to Standard, which looks quite familiar already. It is also further conceivable that one good day, leveraging the same principles, a fellow starts a sister project to Standard covering the data science use cases, instead. Such use case diversity would serve all parties by improving code quality and further expanding the productivity toolset of Standard users.

As per @jorsn's stated need from above, once the dust settles, all this should help using nix as opposed to playing with nix by leveraging similar mental models and organizational principles for productivity.

[blaggacao]

@jorsn This is a draft, but maybe you have some early feedback as I do the write-up...

# Standard vs X

_Where appropriate, we compare with `divnix/paisano`, instead_.

## In the Nix ecosystem ...

### flake-utils

Flake utils is a small utility with a focus on _generating `flake.nix` files_.
Paisano, in turn, is an importer with a focus on _code organization_.
It also plugs well into a `flake.nix` file and preserves its index function by keeping it clean.

### flake.parts

Flake parts is a component aggregator with a focus on `flake.nix` schema.
Paisano is a component organizer and to a lesser extend aggregator that gives you the freedom to use the schema that best fits your problem domain.
Convergence towards the Flakes output schema is provided via the harvester family of functions (`winnow`, `harvest` & `pick`).
Depending on the domain schema, that convergence _can_ be lossy, due to Flake's lesser expresivity.

### Devshell

Here, it's not a "vs" but an "and".
Standard wraps `numtide/devshell` to improve the developer experience in the early parts of the SDLC via reproducible development shells.

## In the SDLC space ...

### My language build tool

Note: wrapped

### My language module system

Note: Pretty much the same, but in the nix world, "module" has a different meaning.

### Bazel

Note: bazel wins cycle time due to language level caching support

### My CI/CD

Note: fully integrated; registry is the flexible metadata interface

> e.g. GitHub Actions / GitLab Pipelines

[nrdxp]

Note: bazel wins cycle time due to language level caching support

But loses everything else because Java :trollface: (couldn't resist sorry)

[blaggacao]

https://std.divnix.com/COMPARE.html — Hope it's a step in the right direction, together with the architecture.