-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
review pass on tutorial sections #806
review pass on tutorial sections #806
Conversation
- link to reference documentation on the `builder` executable - since the sandbox is enabled by default, we can just say that
- sharpen the value proposition of the library - this meshes with and expands on the new title
since the title is now different, we can be more specific on what the first section is about: file sets, generally.
brackets in console output invoke weird associations, as they could be syntactically relevant. bare ellipses are unusual enough one can expect them to be intuitively parsed as artificial.
three highlight boxes in a row seem a bit too much, also the tip is relevant immediately after the first example.
- more telling section title - use imperative in instructions
this follows the convention established in the FAQ on releases
this follows the convention established in other tutorials. also arguably, this file is *not* the package per se, but simply contains a representation of build instructions.
otherwise the examples don't actually work
- readers may not have literally seen the examples - "combinators" isn't even used in reference documentation and is a potentially scary word. it doesn't even convey additional meaning here, since combination ("two together") and composition ("put together") are almost the same, composition being more general.
it's a huge diff, but it doesn't change that much: - start with a `mkDerivation` scaffold that uses `src = ./.` - this saves the detour with an intentionally broken derivation and the explanation it requires - it provides an opportunity to drop another bit of information about `toSource`, namely that it always creates a directory in the store - use two source files to start with, otherwise the "try one file, then the whole directory" approach is not well-motivated - this obviates spending words on justifying a contrived example, it flows more naturally - mostly use diffs to highlight the changes - this is not a strong proposal - the explicit-include-union example starts over, so the build-up is manageable - it works out quite nicely overall: since there is sufficient repetition where we reasonably expect learners to have gotten the point, the last two sections can be reduced just to the relevant bit. - rename section headers to match functions, not domain problems - one exception is the split of the two union approaches, which should be okay - reword all instructions to be imperative the review made clear how powerful and elegant the library is, and that the tutorial is utterly well-structured and ordered in a way that feels natural and covers all important aspects! great job!
Nah, please someone tell that Vale thing to shut up. I'm really done for today. |
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.
Awesome, thanks a lot! Here are some minor counter-suggestions :P
sources ? import ./nix/sources.nix, | ||
inputs ? import ./nix/sources.nix, |
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.
You used sources
in the pinning tutorial, which I mirrored: https://nix.dev/guides/recipes/dependency-management 😄
I'm fine either way though :)
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.
Ah, oh. Apparently I refrained from actually committing to that, but it stuck after spending a bit of time thinking it through. Now I remember: I didn't pull through because it would diverge from niv
upstream docs and likely confuse people. Sorry for the detour.
(I still think we should consider converging with flake conventions, inputs
or sources
, either way. sources
has some appeal because this is what the references are about: remote sources of... stuff. inputs
is so generic to the point it's meaningless; but maybe that's good? At least they aren't even necessarily used as build inputs. Anyway, doesn't matter here.)
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Suggestion stand-off! Feel free to merge what you like, it's all yours after all. |
Nice, thanks! Let's merge this one into #802 now :) |
it's a huge diff, but it doesn't change that much:
mkDerivation
scaffold that usessrc = ./.
the explanation it requires
toSource
, namely that it always creates a directory in the storethe whole directory" approach is not well-motivated
it flows more naturally
manageable
where we reasonably expect learners to have gotten the point,
the last two sections can be reduced just to the relevant bit.
be okay
the review made clear how powerful and elegant the library is, and that the
tutorial is utterly well-structured and ordered in a way that feels natural
and covers all important aspects!
great job @infinisil!