410c325b18
* "Misc" use was disputed, moving back to use of the "Additional" category. * Using a (link) pattern for URLs, reasons being: * Including the markup into the outlines or hyperlinks considered a bad practice and should be used carefully. * The human cause: The reason for the changelog is so people read through it and get the info. Hyperlinks make text colored. Studies of readability have shown that people perceive the information of a brightly colored text much more poorly than the text of regular coloring. And delivering the meaning is what changelog text is for, so the informative text should be regularly colored. * The technical cause - the Hackage does not parse the markup inside the hyperlinks: https://hackage.haskell.org/package/hnix-0.10.0/changelog Probably because of the reason *1, but Hackage reason alone is enough. * Since people perceive and think about the read information mostly linearly and in the FIFO manner, `(link)` is put before information text, so links are placed in the same space and look more uniform upon reading. And upon reading the "link" context gets pushed first from the FIFO mind buffer and the further understanding the text the person is not distracted by sudden reading (taking-in) of the colored word "link" in the end of the semantically challenging text that is required to be understood. * Dependency requirements of last major versions made literal. * Link to `(diff)` made more obvious. While professionals tend to look for the link to the full diff, diff under version number is ambiguous to where the version number link leads, it can be for example: a GitHub release (where different forms of packages are provided), diff, commit listing (as it was before the current change), official forum post, official news... etc. * Made `(diff)` link to point directly towards the diff. |
||
---|---|---|
.github/workflows | ||
benchmarks | ||
data | ||
doc | ||
main | ||
src | ||
tests | ||
.gitignore | ||
.gitmodules | ||
brittany.yaml | ||
build.sh | ||
cabal.project | ||
CHANGELOG.md | ||
CODEOWNERS | ||
default.nix | ||
hnix.cabal | ||
hydra.json | ||
jobsets.nix | ||
LICENSE | ||
Makefile | ||
README-design.md | ||
README.md | ||
release.nix | ||
Setup.hs | ||
shell.nix |
hnix
CI | |
---|---|
Haskell parser, evaluator and type checker for the Nix language.
Prerequisites
Nix is installed and in your $PATH
. This is so that nix-store
can be used
for interacting with store paths, until hnix-store
is ready.
Getting Started
$ git clone --recursive https://github.com/haskell-nix/hnix.git
...
$ cd hnix
$ nix-shell
$ cabal v2-configure --enable-tests
$ cabal v2-build
$ cabal v2-test
# To run all of the tests, which takes up to a minute:
$ env ALL_TESTS=yes cabal v2-test
# To run only specific tests (see `tests/Main.hs` for a list)
$ env NIXPKGS_TESTS=yes PRETTY_TESTS=1 cabal v2-test
$ ./dist/build/hnix/hnix --help
Using the REPL
To enter the hnix
REPL use
hnix --repl
To evaluate an expression and make it available in the REPL
as the input
variable use
hnix --eval -E '(import <nixpkgs> {}).pkgs.hello' --repl
Use the :help
command for a list of all available REPL commands.
Building with full debug info
To build hnix
for debugging, and with full tracing output and stack traces,
use:
$ nix-shell
$ cabal v2-configure --enable-tests --enable-profiling --flags=profiling --flags=tracing
$ cabal v2-build
$ ./dist/build/hnix/hnix -v5 --trace <args> +RTS -xc
Note that this will run quite slowly, but will give the most information as to what might potentially be going wrong during parsing or evaluation.
Building with benchmarks enabled
To build hnix
with benchmarks enabled:
$ nix-shell --arg doBenchmarks true
$ cabal v2-configure --enable-tests --enable-benchmarks
$ cabal v2-build
$ cabal v2-bench
Building with profiling enabled
To build hnix
with profiling enabled:
$ nix-shell
$ cabal v2-configure --enable-tests --enable-profiling --flags=profiling
$ cabal v2-build
$ ./dist/build/hnix/hnix <args> +RTS -p
Building with GHCJS
From the project root directory, run:
$ NIX_CONF_DIR=$PWD/ghcjs nix-build ghcjs
This will build an hnix
library that can be linked to your GHCJS
application.
Using the Cachix binary cache
If you're on macOS, you can use the binary cache at Cachix to avoid building the specific dependencies used by hnix. Just use these commands:
$ nix-env -iA cachix -f https://github.com/NixOS/nixpkgs/tarball/db557aab7b690f5e0e3348459f2e4dc8fd0d9298
$ cachix use hnix
How you can help
Issue Tracker Backlog
If you're looking for a way to help out, try taking a look here. When you find an issue that looks interesting to you, comment on the ticket to let others know you're working on it; look for others who might have done the same. You can talk with everyone live on Gitter.
When you're ready to submit a pull request, test it with:
$ git submodule update --init --recursive
$ nix-shell --run "LANGUAGE_TESTS=yes cabal v2-test"
Make sure that all the tests that were passing prior to your PR are still passing afterwards; it's OK if no new tests are passing.
Evaluating Nixpkgs with HNix
Currently the main high-level goal is to be able to evaluate all of nixpkgs. To
run this yourself, first build hnix with nix-build
, then run the following
command:
$ ./result/bin/hnix --eval -E "import <nixpkgs> {}" --find