Expand and improve the Module System tutorial about nix.dev

[autra]

Sounds really nice! I had started to rewrite the "deep dive" tuto using open services (osm mainly) but frankly, I'm not sure it is a good idea: the deep dive might be funny to follow and imo works well in a workshop, but it's not a very real packaging use case. Also I'm quite new in the nix world, and I suspect part of it are outdated (but can't really judge for sure).

I think that from a newcomer perspective (I've only started learning nix in 2024), there is a gap just before the "packaging existing software" page on nix.dev, which some of your first lessons could very well fill even before the "deep dive" page.

Add more lessons. What I have is not comprehensive and is just sufficient to get someone started on the module system. There is much more to explain and document.

Especially, nixpkgs and the library it provides is still a lot more unknown to me that nix (the language) itself. It would be nice to have some lessons about it

Anyway, if you need a guinea pig for your pull requests, don't hesitate to ping me :-)

[djacu]

@fricklerhandwerk my idea for merging was to leave the current deep dive alone until we had a decent amount of content migrated. There are definitely a lot more details to work out so I'll try to be at the Thursday meeting. That's what you meant by office hours, right?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-04-25-documentation-team-meeting-notes-122/44080/1

[fricklerhandwerk]

Sorry for not commenting earlier, my notification queue is too long.

The infra aspect is really good and generally desirable, especially if it's somewhat transparent how it works and thus easy to maintain or create new samples.

Concerning the migration or merging of contents, I think it's a very good idea because the deep dive has a couple structural issues. I'm just a bit skeptical how exactly to approach such a lengthy and review-intensive process such that we won't have two construction sites next to each other for an indefinite amount of time.

One of my primary goals is for nix.dev to be small but authoritative (in the sense of "exactly one, working solution to each problem"), which kind of precludes showing essentially equivalent alternatives. I know, we're not very far with that. @djacu maybe you drop into one of the office hours and we figure out how to move forward in a high bandwidth conversation?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-05-16-documentation-team-meeting-notes-128/45537/1