| 4 Nov 2023 |
 antifuchs | Oooh, I didn’t know about that yet! Looks very useful indeed | 18:32:43 |
| 5 Nov 2023 |
|  @atka:matrix.org joined the room. | 01:18:52 |
 infinisil | antifuchs: I do think the order is somewhat important. In particular lib.path, lib.filesystem and lib.sources/lib.fileset should be in that order, because they build up on the previous one | 10:54:23 |
| infinisil | But then again, the path library also isn't that important, maybe it ahould come last :P | 10:55:04 |
| infinisil | I guess I don't care very much tbh :) | 10:55:20 |
| antifuchs | hahaha, makes sense | 14:02:03 |
| antifuchs | if there are logical groupings, maybe we can arrange them via subsections? but I think in source, having the library attributes be alphabetical would make it much easier to do a mental tally | 14:02:40 |
| 6 Nov 2023 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
antifuchs: I do think the order is somewhat important. In particular lib.path, lib.filesystem and lib.sources/lib.fileset should be in that order, because they build up on the previous one that's too much inference, and nobody expect much from an ordered lists, because dependency graphs > 3 nodes are basically never ordered lists | 11:51:53 |
| Robert Hensing (roberth) | subsections can only represent trees, and only if they're not too deep, so those are not suitable either | 11:52:51 |
| infinisil | I guess just an introductory section giving an overview of all sublibraries would be better | 11:53:22 |
| Robert Hensing (roberth) | if at all. Most library reference material doesn't bother with that kind of thing | 11:54:04 |
| Robert Hensing (roberth) | not sure that we should | 11:54:11 |
 alejandrosame | In reply to @antifuchs:asf.computer
fricklerhandwerk: while I have your attention on the library TOC, do you think it (https://nixos.org/manual/nixpkgs/unstable/#sec-functions-library) should be sorted alphabetically? the order doesn't make much sense to me and that makes it difficult to find things that are missing For reference documentation I'm also more into alphabetical order and then linking as necessary to building blocks (for example, the proposal in https://github.com/NixOS/nixpkgs/issues/250376).
Other types of documents can order as they want, ofc, since the whole point is to set up an order that makes sense for storytelling, task completion, etc.
| 12:20:20 |
 proofconstruction | In reply to @infinisil:matrix.org
I guess just an introductory section giving an overview of all sublibraries would be better This would be better as a page on nix.dev | 14:36:53 |
| infinisil | Hmm I think reference docs can also use overviews of its parts, it doesn't really fit into tutorials, guides or explanation | 14:39:47 |
 fricklerhandwerk | Overviews are important, and should be right there with the reference docs. Reference will change, and while the prose overview may not catch up immediately, it's way easier to keep it in sync when it's in-tree. | 14:56:28 |
| proofconstruction | In case I just mass review-requested everyone on nix.dev, I apologize. I was trying to fix an erroneous push. Who are the administrators of the repo? We should enable branch protection on master to require a PR with approval before merging | 16:42:33 |
 @delroth:delroth.net | fun artifact of building nix.dev with flakes: the footer says "Copyright 2016-1980" | 16:46:24 |
| @delroth:delroth.net | * fun artifact of building nix.dev with nix: the footer says "Copyright 2016-1980" | 16:46:31 |
 nbp | Wait, this is not 1970? | 16:52:28 |
| alejandrosame | In reply to @infinisil:matrix.org
Hmm I think reference docs can also use overviews of its parts, it doesn't really fit into tutorials, guides or explanation The way I see it is like dictionaries: you can add extra sections (intros, overviews, historical explanations, etc) but the indexing of the entries is alphabetical to ease its navigation. | 17:02:30 |
| alejandrosame | I'm with you that being too terse is in general problematic for documentation. | 17:04:09 |
| @delroth:delroth.net | In reply to @nbp:mozilla.org
Wait, this is not 1970? I think 1980 is the default SOURCE_DATE_EPOCH | 17:51:44 |
| nbp | isn't that the 1st of 1970? To which we added a few seconds because of gnumake? | 18:02:01 |
 Linux Hackerman | ZIP can only represent dates starting from 1980, my guess is that that's why it would be 1980 and not 1970 | 18:04:44 |
| @delroth:delroth.net | # Set a fallback default value for SOURCE_DATE_EPOCH, used by some build tools
# to provide a deterministic substitute for the "current" time. Note that
# 315532800 = 1980-01-01 12:00:00. We use this date because python's wheel
# implementation uses zip archive and zip does not support dates going back to
# 1970.
export SOURCE_DATE_EPOCH
: "${SOURCE_DATE_EPOCH:=315532800}"
| 18:28:44 |
| infinisil | I've drafted a small RFC to use nix.dev as the canonical name (but there's also alternatives), would appreciate some quick feedback: https://github.com/nix-rfc-canonical-domain/rfcs/blob/canonical-domain/rfcs/1000-canonical-domain.md | 20:36:48 |
| infinisil | * I've drafted a small RFC to use nix.dev as the canonical domain name (but there's also alternatives), would appreciate some quick feedback: https://github.com/nix-rfc-canonical-domain/rfcs/blob/canonical-domain/rfcs/1000-canonical-domain.md | 20:37:52 |
| fricklerhandwerk | In reply to @infinisil:matrix.org
I've drafted a small RFC to use nix.dev as the canonical domain name (but there's also alternatives), would appreciate some quick feedback: https://github.com/nix-rfc-canonical-domain/rfcs/blob/canonical-domain/rfcs/1000-canonical-domain.md There should be very few things that deserve an RFC. This is one of them. | 20:41:34 |
| @delroth:delroth.net | this feels like it should have a mention of the nixos dot com problem :-) | 20:44:40 |
