Skip to content
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

Merged
merged 7 commits into from
Jan 2, 2023

Conversation

fricklerhandwerk
Copy link
Contributor

this continues the effort from #6420, which originally began with #4280.

@abathur
Copy link
Member

abathur commented Sep 20, 2022

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.)

@fricklerhandwerk
Copy link
Contributor Author

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!

@abathur
Copy link
Member

abathur commented Sep 20, 2022

Fine answers for now :)

The consistency of the edits just made me curious.

fricklerhandwerk and others added 4 commits November 9, 2022 01:29
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 <bryan.honof@tweag.io>
this will at some point enable rendering them nicely for the web
the language has its own overview page where its properties are
described in sufficient detail.
@fricklerhandwerk
Copy link
Contributor Author

@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*.
Copy link
Contributor

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

Suggested change
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).

Copy link
Member

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.

Copy link
Contributor Author

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.

doc/manual/src/architecture/architecture.md Outdated Show resolved Hide resolved
@SuperSandro2000
Copy link
Member

Could we use mermaid to draw the diagrams instead of manually doing them?

@fricklerhandwerk
Copy link
Contributor Author

@SuperSandro2000 I tried that first, since of course it's insane to maintain ASCII diagrams but unfortunately it doesn't work:

  • Mermaid doesn't offer enough control over presentation. It very quickly looks unnecessarily messy.
  • There is no ASCII rendering for Mermaid, which we need for terminal output (man and --help), and I can't imagine how that would be less messy if it existed.
  • Mermaid requires adding a huge closure the manual build to display the diagrams at all.

svgbob renders these things good enough, and allows us to have both presentations. Using it is optional since just having the ASCII is already better than no visualisation at all. We can always upgrade to a more convenient method once we find one.

@edolstra said he doesn't like the brittle custom syntax, and I concur with a smirk that

It's like markdown brought to its bitter conclusion.

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:

  • LaTeX could work, but this is only slightly less cumbersome and needs tons of specialised knowledge to maintain.
  • Building something with some SVG or diagramming tool and committing both the source and the final rendering is possible in principle. But it makes the contribution process really cumbersome, due to the manual steps, requires contributors to install and learn using a very specific tool, and I know none that would give us ASCII output as well.

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.
Copy link
Member

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*.
Copy link
Member

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.

doc/manual/src/architecture/architecture.md Outdated Show resolved Hide resolved
doc/manual/src/architecture/architecture.md Outdated Show resolved Hide resolved
@fricklerhandwerk
Copy link
Contributor Author

fricklerhandwerk commented Dec 19, 2022

Discussed in depth on Nix team meeting on 2022-12-12.

Decision: fix up wording and continue async with merging

Complete discussion
  • @edolstra: ASCII diagrams are okay for documentation that is not user-facing
    • @fricklerhandwerk: the only reason this is not in the man pages is that no one set it up yet
      • @edolstra: we probably don't want it there either
        • @fricklerhandwerk: why not? having offline documentation doesn't cost us much and can be invaluable in some situations.
    • ability to render ASCII art should not be a blocker to include graphics
      • @fricklerhandwerk: agreed, but it should be kept as consideration. it would be good to include diagrams in the terminal output if we have them, and they are simple enough for it to be realistic
  • @Eriscon2314: summary: we want to have SVG for the HTML rendering, and edit conveniently
  • @thufschmitt: PlantUML also renders ASCII https://plantuml.com/en/ascii-art
    • @fricklerhandwerk: apparently only for sequence diagrams.
    • @thufschmitt: also requires a huge closure
      • @fricklerhanderk: any tool that does these transformations will; choose your poison
  • decision: leave the ASCII for now, consider moving to SVG later
  • @edolstra: which level of architecture is supposed to be documented here?
  • @edolstra: graph arrows and labels are not entirely clear about what they mean
    • @fricklerhandwerk: the point is to have a general overview, and the subsections will go into details on each term and concept
  • (some more discussion over wording and intent)
  • decision: fix up wording and continue async with merging
  • assigned to @edolstra

@nixos-discourse
Copy link

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.
@thufschmitt thufschmitt merged commit a654ae8 into NixOS:master Jan 2, 2023
@nixos-discourse
Copy link

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

@fricklerhandwerk fricklerhandwerk deleted the architecture-overview branch January 3, 2023 12:47
@nixos-discourse
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

8 participants