!avYyleMexqjFHoqrME:nixos.org

Nix Documentation

439 Members
Discussion about documentation improvements around the Nix ecosystem93 Servers

Load older messages


SenderMessageTime
17 Jul 2023
@Ericson2314:matrix.orgJohn EricsonI get that flakes have driven a lot of new usage, but that is just because everything else was so unpolished18:30:11
@Ericson2314:matrix.orgJohn Ericsonthe bar was so low18:30:15
@Ericson2314:matrix.orgJohn Ericson Flakes are a "fast food" that kinda tastes good to start but ultimately fails to truly solve any problems 18:30:45
@Ericson2314:matrix.orgJohn EricsonWe have to believe the choices are not just "Flakes" or "unpolished unusuable to non-experts"18:31:32
@asymmetric:matrix.dapp.org.ukasymmetric
In reply to @infinisil:matrix.org
This would also set a precedent that the docs team will document whatever ill-designed and barely-documented feature gets merged into Nix
I agree with most of your other points, but this precedent has definitely already been set by stable nix+nixpkgs, at least the part about us having to ex post document barely-documented stuff
18:32:23
@infinisil:matrix.orginfinisilWe can't deny that Flakes does solve some problems. Though it also introduces a whole bunch of new problems along the way, problems which shouldn't be necessary18:32:36
@infinisil:matrix.orginfinisil
In reply to @asymmetric:matrix.dapp.org.uk
I agree with most of your other points, but this precedent has definitely already been set by stable nix+nixpkgs, at least the part about us having to ex post document barely-documented stuff
Hehe fair enough, would like to get away from that though :P
18:33:17
@asymmetric:matrix.dapp.org.ukasymmetric
In reply to @Ericson2314:matrix.org
Flakes are a "fast food" that kinda tastes good to start but ultimately fails to truly solve any problems
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, and it is factually still experimental, so I think we should focus on that, rather than value judgements
18:33:32
@asymmetric:matrix.dapp.org.ukasymmetric
In reply to @Ericson2314:matrix.org
Flakes are a "fast food" that kinda tastes good to start but ultimately fails to truly solve any problems
* 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:matrix.dapp.org.ukasymmetric * 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
@Ericson2314:matrix.orgJohn Ericsonopinions are somewhat inevitable for writing tutorials not reference docs18:35:06
@Ericson2314:matrix.orgJohn Ericsonthe fact here is that flakes are unstable and unstable has to mean something18:35:23
@Ericson2314:matrix.orgJohn EricsonFlakes creating problems as fast as they solve problems I suppose could be an opinion18:36:18
@Ericson2314:matrix.orgJohn Ericsonbut we can focus on the above an ignore that18:36:24
@Ericson2314:matrix.orgJohn Ericsonif we want to stick to "facts" and avoid "opinions"18:36:40
@asymmetric:matrix.dapp.org.ukasymmetric
In reply to @Ericson2314:matrix.org
the fact here is that flakes are unstable and unstable has to mean something
yeah fully agreed on that. which i think is why we decided to draw the line there for nix.dev 🙂
18:36:42
@Ericson2314:matrix.orgJohn Ericson:)18:36:50
@Ericson2314:matrix.orgJohn Ericson<318:36:55
@asymmetric:matrix.dapp.org.ukasymmetricthe 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 level18:37:53
@asymmetric:matrix.dapp.org.ukasymmetric * 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 level18:38:17
@brian:bmcgee.ie@brian:bmcgee.ie
In reply to @infinisil:matrix.org
I really like John Ericson's suggestions for what Nix should become here: https://github.com/NixOS/rfcs/pull/136#discussion_r1246035453
I like the idea of a stripped down nix core with things like flakes becoming a different frontend.
18:38:39
@brian:bmcgee.ie@brian:bmcgee.ieIt 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 part18:42:09
@infinisil:matrix.orginfinisilI have an RFC draft that if accepted would be a really big step towards that18:43:30
@brian:bmcgee.ie@brian:bmcgee.ieLink please 18:44:04
@brian:bmcgee.ie@brian:bmcgee.ieIf it's up sonewhere18:44:21
@brian:bmcgee.ie@brian:bmcgee.ie* If it's up somewhere18:44:28
@infinisil:matrix.orginfinisilIt'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/epcb18:44:28
@infinisil:matrix.orginfinisilWell, it's a mess of old and new drafts, don't read it too closely, but feel free to ask me questions if confused18:46:25
@infinisil:matrix.orginfinisilBtw this is using the repository-as-RFC approach proposed in https://github.com/NixOS/rfcs/pull/13818:47:27
@raitobezarius:matrix.orgraitobezarius
In reply to @brian:bmcgee.ie
I lean more Domen Kožar's direction on this one for the simple reason that the majority of my 2 years with Nix has been flake-oriented. The only time I write a shell.nix is to make a project compatible for non flake users. There are valid concerns about flakes and a need to stabilise them. Maybe I'm putting effort in the wrong place and should be helping to stabilise flakes like you said infinisil rather than putting effort into documenting a workflow I choose not to use on a daily basis (and I say this without any kind of snark or ill feeling).

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

Show newer messages


Back to Room ListRoom Version: 6