* tutorial: Propagate previous geocode changes
Propagate the changes made in a previous code snippet to this code
snippet. Primarily fixing the poorly referenced ``${geocode``.
* tutorial: Fix requestParams for path.nix
Adjust the functionality to reference geocode correctly and
also to make sure of the correct escaping formats.
Signed-off-by: Brian McGillion <bmg.avoin@gmail.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
previously, stderr was garbled, which made it really annoying to deal
with build errors.
it turns out that the library wrapper around calling a process is not
just counterproductive, but also completely unnecessary.
the build now takes longer because it's not incremental any more.
but the problem with `sphinx-build` in a shell environment is that it
doesn't keep track of an entire class of files, that would have to be
considered manually. this is too much manual overhead that doesn't scale
at all. with the new setup the live preview will do exactly what the
final deployment does.
[1]: https://github.com/executablebooks/sphinx-autobuild#relevant-sphinx-bugs
Co-authored-by: Alex Groleau source@proof.construction
* mv question -f faqs -t nix-recipes
* add nix-recipes to page index and fix hierarchy
* change question to statement
* rephrase a few sentences and add links
* move the question to troubleshooting
* fix broken link
---------
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
* shorten the sharing dependencies article to a guide
the contents do not really warrant a full-blown tutorial
* use an example with an explicit build-time dependency
* fix typo
* link `inputsFrom` to Nixpkgs manual
The current code has a number of issues.
1. realising the code results in:
``
markers=$(geocode 'New York') size=640x640 scale=2 zoom=7 ...
^-------------------^ SC2046 (warning): Quote this to prevent
word splitting.
``
2.
``
$(geocode ${lib.escapeShellArg marker.location})"
``
Assumes that geocode has been added to the PATH so replace with
``
${config.scripts.geocode}/bin/geocode
``
as per previous examples.
3.
``
in "markers=${ lib.concatStringsSep "\\|" attributes}";
in builtins.map paramForMarker config.map.markers;
``
The ordering of this actually creates multiple ``[markers =]``
parameters and does not use the concatenation string to join the
attributes together (in effect there is only 1 attribute per call) to
map, and 1 new ``marker`` created.
Signed-off-by: Brian McGillion <bmg.avoin@gmail.com>
* tutorials: fix passing paramaters to geocode
When running the package as-is the following error occurs
``geocode: line 7: $1: unbound``
This is caused because ``scripts.geocode`` does not pass the parameters
down to the wrapped script ``geocode``.
Signed-off-by: Brian McGillion <bmg.avoin@gmail.com>
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>
