-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
manual: architecture overview #7066
manual: architecture overview #7066
Conversation
Aside: will there be a ~style guide with notes on some of the substitutions like action->task and perform->run? (Unclear from casual observation if these are just cases where you're being consistent about choosing simpler words or if this is more about using a consistent, precise vocabulary.) |
Good question. I think this is not yet worth a firm rule. Here it's just about finding more appropriate terminology and being consistent about it. If people find it reasonable we can just continue using it, and watching out in reviews to keep it consistent. We discussed this up and down in the making of #6420, and I'm fairly convinced now that this is both correct and appealing to common sense. Of course still open to constructive disagreement! |
Fine answers for now :) The consistency of the edits just made me curious. |
e0c7f4b
to
7a4edde
Compare
these changes were not merged properly and had to be reverted. see merge commit d8e54d1 for full history leading up to here.
Co-authored-by: Bryan Honof <[email protected]>
this will at some point enable rendering them nicely for the web
7a4edde
to
3d716df
Compare
the language has its own overview page where its properties are described in sufficient detail.
@edolstra please review, this is now a pure addition, and a fairly small one at that. |
Underlying the command line interface and the Nix language is the [Nix store](../glossary.md#gloss-store), a mechanism to keep track of build plans, data, and references between them. | ||
It can also execute build plans to produce new data. | ||
|
||
A build plan is a series of *build tasks*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it a bit counterintuitive that the first term introduced is "build task", only then for the term to be redefined in a "boxed paragraph".
Also, by introducing this term ("build task"), I think you're increasing the cognitive load, as it is not going to be useful in the broader Nix context.
My suggesiton is instead
A build plan is a series of *build tasks*. | |
A build plan is a series of "build tasks", which in Nix are called [derivations](../glossary#gloss-derivation). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, maybe it's better to use "derivation" instead of "build task", which is not a term that appears in the Nix source.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still don't have a definition of what exactly a derivation even is. I'd argue the term derivation should be reserved for Nix's specific implementation of build tasks, whatever it is we define it to be - store derivation or the Nix language concept.
Could we use mermaid to draw the diagrams instead of manually doing them? |
@SuperSandro2000 I tried that first, since of course it's insane to maintain ASCII diagrams but unfortunately it doesn't work:
@edolstra said he doesn't like the brittle custom syntax, and I concur with a smirk that
I'm agnostic to the tools we use, as long as they get the job done. Right now I don't see a meaningful alternative. A few considerations:
Do you have other suggestions? |
> As far as we are concerned here, the inputs and results of a build plan are just data. | ||
|
||
Underlying the command line interface and the Nix language is the [Nix store](../glossary.md#gloss-store), a mechanism to keep track of build plans, data, and references between them. | ||
It can also execute build plans to produce new data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"It" here seems to refer to the Nix store, which cannot be said to execute build plans.
Underlying the command line interface and the Nix language is the [Nix store](../glossary.md#gloss-store), a mechanism to keep track of build plans, data, and references between them. | ||
It can also execute build plans to produce new data. | ||
|
||
A build plan is a series of *build tasks*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, maybe it's better to use "derivation" instead of "build task", which is not a term that appears in the Nix source.
62a11bf
to
4ed8bb1
Compare
Discussed in depth on Nix team meeting on 2022-12-12. Decision: fix up wording and continue async with merging Complete discussion
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2022-12-12-nix-team-meeting-minutes-16/24119/1 |
this is to help reading the diagrams, otherwise arrows and labels were reported as being ambiguous.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-01-02-nix-team-meeting-minutes-20/24403/1 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nix-team-report-2022-10-2023-03/27486/1 |
this continues the effort from #6420, which originally began with #4280.