 | Nix Documentation | 415 Members |
| Discussion about documentation improvements around the Nix ecosystem | 84 Servers |
| Nix Documentation | 415 Members |
| Discussion about documentation improvements around the Nix ecosystem | 84 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2023 | ||
 infinisil | In reply to @asymmetric:matrix.dapp.org.ukHehe fair enough, would like to get away from that though :P | 18:33:17 |
 asymmetric | In reply to @Ericson2314:matrix.orgi think this is subjective. i really like flakes and for my usecases, they have almost completely replaced the stable tooling. but the other problems still stand, and it is factually still experimental, so I think we should focus on that, rather than value judgements | 18:33:32 |
| asymmetric | In reply to @Ericson2314:matrix.org* i think this is subjective. i really like flakes and for my usecases, they have almost completely replaced the stable tooling. but the other problems still stand (missing feature parity), and it is factually still experimental, so I think we should focus on that, rather than value judgements | 18:33:50 |
| asymmetric | * i think this is subjective. i really like flakes and for my usecases, they have almost completely replaced the stable tooling. but the other problems still stand (e.g. missing feature parity), and it is factually still experimental, so I think we should focus on that, rather than value judgements | 18:34:42 |
 John Ericson | opinions are somewhat inevitable for writing tutorials not reference docs | 18:35:06 |
| John Ericson | the fact here is that flakes are unstable and unstable has to mean something | 18:35:23 |
| John Ericson | Flakes creating problems as fast as they solve problems I suppose could be an opinion | 18:36:18 |
| John Ericson | but we can focus on the above an ignore that | 18:36:24 |
| John Ericson | if we want to stick to "facts" and avoid "opinions" | 18:36:40 |
| asymmetric | In reply to @Ericson2314:matrix.orgyeah fully agreed on that. which i think is why we decided to draw the line there for nix.dev 🙂 | 18:36:42 |
| John Ericson | :) | 18:36:50 |
| John Ericson | <3 | 18:36:55 |
| asymmetric | the corollary is that once they're stabilized, we should imo just go ahead and document them on nix.dev, even though some of us will still disagree with them on a design level | 18:37:53 |
| asymmetric | * the corollary is that once (if!) they're stabilized, we should imo just go ahead and document them on nix.dev, even though some of us will still disagree with them on a design level | 18:38:17 |
 @brian:bmcgee.ie | In reply to @infinisil:matrix.orgI like the idea of a stripped down nix core with things like flakes becoming a different frontend. | 18:38:39 |
| @brian:bmcgee.ie | It would allow for faster iteration in different areas too since you've broken out the use cases. Getting the core right is gonna be the tricky part | 18:42:09 |
| infinisil | I have an RFC draft that if accepted would be a really big step towards that | 18:43:30 |
| @brian:bmcgee.ie | Link please | 18:44:04 |
| @brian:bmcgee.ie | If it's up sonewhere | 18:44:21 |
| @brian:bmcgee.ie | * If it's up somewhere | 18:44:28 |
| infinisil | It's really draft right now, but because I don't have a lot of time to work on it right now I'm sharing it in the hopes of others being able to help out with it, PR's and issues appreciated: https://github.com/tweag/epcb | 18:44:28 |
| infinisil | Well, it's a mess of old and new drafts, don't read it too closely, but feel free to ask me questions if confused | 18:46:25 |
| infinisil | Btw this is using the repository-as-RFC approach proposed in https://github.com/NixOS/rfcs/pull/138 | 18:47:27 |
 raitobezarius | In reply to @brian:bmcgee.ie Just to provide another datapoint: I have spent my last years removing Flakes from project (latest example in mind is bcachefs with an impossible Flake setup…), dealing with people who tries to shoehorn Flakes into the wrong project because it is not fit for it, dealing with a lot of kind of footguns generated by deep dependency management brought by Flakes, etc. While I do understand the value of Flakes and use them sparringly or have projects with them, I am not excited to see documentation team having to focus on that, especially given that most people does not know how to do things the vanilla way (sometimes people do say the "legacy" which irks me the wrong way, because Flakes does not supplement the vanilla usecases yet, for example, try to repair your remote store with the "nix-command" CLI :)) | 19:10:16 |
 @nerves:bark.lgbt joined the room. | 20:29:45 | |
| infinisil | Would like to have some opinions on this: https://github.com/NixOS/nixpkgs/issues/244056 | 21:36:53 |
| 18 Jul 2023 | ||
 nbp | From my point of view, is was kind of part of it, as this was the natural evolution of extending Nixpkgs with a new set of packages. This point was probably more true before the addition of overlays … :/ | 14:42:53 |
| nbp | * infinisil: From my point of view, is was kind of part of it, as this was the natural evolution of extending Nixpkgs with a new set of packages. This point was probably more true before the addition of overlays … :/ | 14:43:18 |
| nbp | Maybe a work-around would be to index the Markdown files, saying that the everything related to submitting patches upstream, in Nixpkgs, would be describe in a set of files which are part of the distributed sources. | 14:44:44 |
 mikecm joined the room. | 15:39:24 | |