nixpkgs/pkgs/development/interpreters/dhall/build-dhall-package.nix

91 lines
2.7 KiB
Nix
Raw Normal View History

{ dhall, dhall-docs, haskell, lib, lndir, runCommand, writeText }:
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
{ name
# Expressions to add to the cache before interpreting the code
, dependencies ? []
# A Dhall expression
#
# Carefully note that the following expression must be devoid of uncached HTTP
# imports. This is because the expression will be evaluated using an
# interpreter with HTTP support disabled, so all HTTP imports have to be
# protected by an integrity check that can be satisfied via cached
# dependencies.
#
# You can add a dependency to the cache using the preceding `dependencies`
# option
, code
# `buildDhallPackage` can include both a "source distribution" in
# `source.dhall` and a "binary distribution" in `binary.dhall`:
#
# * `source.dhall` is a dependency-free αβ-normalized Dhall expression
#
# * `binary.dhall` is an expression of the form: `missing sha256:${HASH}`
#
# This expression requires you to install the cache product located at
# `.cache/dhall/1220${HASH}` to successfully resolve
#
# By default, `buildDhallPackage` only includes "binary.dhall" to conserve
# space within the Nix store, but if you set the following `source` option to
# `true` then the package will also include `source.dhall`.
, source ? false
# Directory to generate documentation for (i.e. as the `--input` option to the
# `dhall-docs` command.)
#
# If `null`, then no documentation is generated.
, documentationRoot ? null
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
}:
let
# HTTP support is disabled in order to force that HTTP dependencies are built
# using Nix instead of using Dhall's support for HTTP imports.
dhallNoHTTP = haskell.lib.appendConfigureFlag dhall "-f-with-http";
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
file = writeText "${name}.dhall" code;
cache = ".cache";
data = ".local/share";
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
cacheDhall = "${cache}/dhall";
dataDhall = "${data}/dhall";
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
sourceFile = "source.dhall";
in
runCommand name { inherit dependencies; } ''
set -eu
mkdir -p ${cacheDhall}
for dependency in $dependencies; do
${lndir}/bin/lndir -silent $dependency/${cacheDhall} ${cacheDhall}
done
export XDG_CACHE_HOME=$PWD/${cache}
mkdir -p $out/${cacheDhall}
${dhallNoHTTP}/bin/dhall --alpha --file '${file}' > $out/${sourceFile}
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
SHA_HASH=$(${dhallNoHTTP}/bin/dhall hash <<< $out/${sourceFile})
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
HASH_FILE="''${SHA_HASH/sha256:/1220}"
${dhallNoHTTP}/bin/dhall encode --file $out/${sourceFile} > $out/${cacheDhall}/$HASH_FILE
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
echo "missing $SHA_HASH" > $out/binary.dhall
${lib.optionalString (!source) "rm $out/${sourceFile}"}
${lib.optionalString (documentationRoot != null) ''
mkdir -p $out/${dataDhall}
XDG_DATA_HOME=$out/${data} ${dhall-docs}/bin/dhall-docs --input '${documentationRoot}' --package-name '${name}' --output-link $out/docs
''}
Add Nixpkgs support for Dhall One of the motivations for this change is the following Discourse discussion: https://discourse.dhall-lang.org/t/offline-use-of-prelude/137 Many users have requested Dhall support for "offline" packages that can be fetched/built/installed using ordinary package management tools (like Nix) instead of using Dhall's HTTP import system. I will continue to use the term "offline" to mean Dhall package builds that do not use Dhall's language support for HTTP imports (and instead use the package manager's support for HTTP requests, such as `pkgs.fetchFromGitHub`) The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds by implementing Nixpkgs support for such builds. That way when other package management tools ask me how to package Dhall with their tools I can refer them to how it is done in Nixpkgs. This change contains a fully "offline" build for the largest Dhall package in existence, known as "dhall-packages" (not to be confused with `dhallPackages`, which is our Nix attribute set containing Dhall packages). The trick to implementing offline builds in Dhall is to take advantage of Dhall's support for semantic integrity checks. If an HTTP import is protected by an integrity check and a cached build product matches the integrity check then the HTTP import is never resolved and the expression is instead fetched from cache. By "installing" dependencies in a pre-seeded and isolated cache we can replace remote HTTP imports with dependencies that have been built and supplied by Nix instead. The offline nature of the builds are enforced by compiling the Haskell interpreter with the `-f-with-http` flag, which disables the interpreter's support for HTTP imports. If a user forgets to supply a necessary dependency as a Nix build product then the build fails informing them that HTTP imports are disabled. By default, built packages are "binary distributions", containing just a cache product and a Dhall expression which can be used to resolve the corresponding cache product. Users can also optionally enable a "source distribution" of a package which already includes the equivalent fully-evaluated Dhall code (for convenience), but this is disabled by default to keep `/nix/store` utilization as compact as possible.
2020-02-12 06:02:53 +00:00
''