historically it still points to Cachix and not to a community-owned
instance. at the moment there is no regular community newsletter, which
would certainly include updates about documentation. we can add it back
once such a thing exists.
this is the most cursed setup you will see any time soon.
we're dumping the Nix manual unchanged into the build tree *after*
building. the reason is that we'd want to link to it from our table of
contents, but because Sphinx does not allow adding arbitrary files to
the build output in arbitrary locations (only `_static` works). but we
want to place the manual behind a particular URL, and the alternative of
maintaining URL rewrites (e.g. in nginx) is not accessible here because the
infrastructure is managed somewhere else.
now that the files won't appear in their desired locations at Sphinx
build time, we can't use relative links to reference them, therefore we
have to resort to pointing to the web URL the manual will appear at.
this is terrible and I'm sorry. please fix this if you have a better
idea. once we use URLs though, we have to avoid linkchecking, since
those files may not be there before deploying them.
figuring all of this out took way longer than anyone would wish.
Co-authored-by: Alejandro Sanchez Medina <alejandrosanchzmedina@gmail.com>
* Draft module system introduction tutorial
* add intro/conclusion, rework prose, follow styleguide, clean diffs
* Review pass
* Apply suggestions from code review
* fix whitespace
* add some more motivation the each section
* make scripts downloadable
* address review comments
* make script actually work
...hopefully. can't test it without Google API key
* add file watching
yes, this looks scary, and yes, it works.
* update diff and wording
* more notes on potential pitfalls
* be explicit which `map` we mean
* split nullable from default values
* also wrap the geocode script
* work through the tutorial to the end
* add tutorial overview
* `lib` is always passed
* add separate section for `evalModules` and fix link
* make option strucutre more self-explanatory
* explain command line invocations
* add note on incomplete reference documentation
* add more highlight to the `config` distinction
* fix parameter passing to the `./map` script
* fix typo
* fix wording
* link to summer of nix
* add missing word
* link to Google Maps API docs
* more explicit requirement
* use correct module system terminology
* Update source/tutorials/module-system/module-system.md
* Apply suggestions from code review
* whitespace
* module-system.md: replace comments with captions
* add missing lang for code-block
* Update module system title
* change most headers to be about module features (#797)
* change most headers to be about module features
Some headers could not be made about module features, and that's a
strong signal that those sections should be removed.
* Apply suggestions from code review
* module-system.md: Fix header casing
Co-authored-by: Alexander Groleau <source@proof.construction>
Co-authored-by: asymmetric <lorenzo@mailbox.org>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
* tutorial: nixos configurations on vm
Co-authored-by: Benoit de Chezelles <bew@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Henrik <i97henka@gmail.com>
Due to an Sphinx issue[1], linkcheck fails on GitHub anchors for
GitHub rendered documents.
This change rewrites the anchors to the ones that can be verified by
linkcheck.
[1]: https://github.com/sphinx-doc/sphinx/issues/9016
There are a number of code samples throughout nix.dev. How do we know
they still work? We don't!
This commit introduces a way for us to extract these code samples into files
and then run tests against them in CI. This will hopefully help us catch
regressions in future updates to nix, NixOS and/or this guide.
Additionally, I included a darwin specific nix-shell configuration that I
use personally on my M1 Mac to work on this repo. Might be useful for someone.
