extended args@ explanation #576
Conversation
|
quite sad that there is no care and interest in making the documentation better |
|
I wouldn't take this personally. Please reopen it and let's just try to catch @edolstra or @shlevy's attention. This repo really just needs more people who can review and merge stuff. @shlevy is super busy with life right now, and @edolstra is central to just about every Nix process and still has a job and a life and all that, so I expect a huge chunk of things escape his attention unless explicitly called out (and even then, there are finite hours in a day). Let's fix the specifics, but let's also fix the process. When I first got commit access to nixpkgs, people warned me not to merge things that I was unsure about. I imagine there are plenty of Nix experts who are still fairly unsure about the Nix codebase, but things like this are safe and uncontroversial and most of us could review and merge it with no input from @edolstra. @edolstra, can we just add a few more Nix old-timers (@aszlig, @domenkozar, @7c6f434c, @garbas, and perhaps others who volunteer) to this repo so things aren't quite as blocked on you, with the understanding that deep functionality changes to Nix (the implementation or the language) still require your approval, and to ping you when in doubt? Giving people a sense of ownership over the repo could also start spreading the knowledge a bit more and motivate people to get better acquainted with the codebase. |
|
@edolstra more concretely, I'd create a separate team in the organization for each (major) repository, to make it clear who can commit to each of Nix, NixOps, Hydra, and nixpkgs. I see you currently have a team for NixOps, but it's still not entirely clear who has access to commit to Nix, so we don't even know who to highlight besides you and @shlevy (whom we've learned by observing can also commit here). I'm assuming @rbvermaa can commit, but don't know if anyone else can. Some transparency in who to ping would probably go a long way, but extending that list in the longer run seems like the sustainable approach. |
|
|
||
| Here <varname>args</varname> is bound to the entire argument, which | ||
| is further matched against the pattern <literal>{ x, y, z, | ||
| ... }</literal>.</para></listitem> | ||
|
|
||
| ... }</literal>. This <literal>@</literal>-pattern makes mainly sense with an |
|
@domenkozar thanks for your feedback |
|
|
||
| but can also be written as: | ||
|
|
||
| <programlisting> { x, y, z, ... } @ args: z + y + x + args.a</programlisting> | ||
|
|
||
| Here <varname>args</varname> is bound to the entire argument, which |
There was a problem hiding this comment.
I don't understand what this means: args is bound to the entire argument, which is further matched against the pattern { ... }
There was a problem hiding this comment.
(this snippet was there before, FYI) The idea is that args gets bound to the whole argument passed to the function, and also the "pattern matches" inside of the { ... } match against the same argument.
There was a problem hiding this comment.
I don't see much advantage with having these two different styles. I have mostly seen the first style in nixpkgs. Could we recommend using the first? I think it's nicer to read code that is consistent.
|
FYI, I don't follow this repo but if anyone tags me I'll at least take a look and respond. |
|
Overall looks good to me, agreed with @domenkozar's comments. Ping me when fixed. |
|
@domenkozar i've taken your two points into account - thanks. paul and me have covered/documented it fairly well in the tour anyways: so if this doesn't make it into the nix documentation, i don't think it would be a huge hit. |
|
@qknight way better now. I'd also add that |
|
@qknight raised a wish to merge this as-is and improve later. I think it already provides value so merging. |
Bump Sphinx and theme
i've build the nix documentation and it builds and looks sane.