Commit Graph

9 Commits

Author SHA1 Message Date
(cdep)illabout
a1933f6a9d dhallPackages.generateDhallDirectoryPackage: init 2021-12-07 13:36:19 +09:00
Dennis Gosnell
4d2b3b4d5a
Merge pull request #142825 from cdepillabout/buildDhallUrl
dhallPackages.buildDhallUrl: add function for easily building dhall remote imports
2021-11-08 13:44:37 +09:00
John Soo
4d821295f1
dhall-grafana: init at 0.1. (#144826) 2021-11-05 20:26:24 -07:00
(cdep)illabout
a201d9744f dhallPackages.buildDhallUrl: add this function
`buildDhallUrl` is a function to download a Dhall remote import.

It is introduced to `dhall-to-nixpkgs` in
https://github.com/dhall-lang/dhall-haskell/pull/2318.
2021-10-25 15:04:50 +09:00
Gabriella Gonzalez
1ae90c5118
dhallPackages: Remove dhall-packages (#138487)
Fixes https://github.com/NixOS/nixpkgs/issues/138374

The build failure in the above issue is due to
`pkgs.dhallPackages.dhall-packages` transitively depending on an
older Prelude version (12.0.0) that is incompatible with newer
Dhall versions.

I first attempted to upgrade `pkgs.dhallPackages.dhall-packages`, but
that failed due to a bad hash on an internal import, so I'm removing
the build instead.
2021-09-19 11:18:00 -07:00
Gabriel Gonzalez
82425ca793 Fix support for extending Dhall package set
* Fix `dhallPackages` to be defined using `callPackage` instead of
  `callPackages`

  This enables the `pkgs.dhallPackages.override` method

* Export `pkgs.dhallPackages.callPackage`

  This is also necessary in order to easily extend `pkgs.dhallPackages` with
  new packages
2021-01-10 10:54:10 +01:00
Gabriel Gonzalez
87d5e6fc1a Change idiom for overriding Dhall package version
Before this change, a Dhall package like the Prelude would be
encoded as a record with one field per supported version.  Then
downstream packages would specify which package to override
by selecting a different record field.

The problem with that approach is that it did not provide an
easy way to override a package to a version other than the default
ones supplied by Nixpkgs.  Normally you would use the `.override`
method for this purpose, but the `override` method added by
`buildDhall{Directory,GitHub}Package` is clobbered by the
`override` method added by `callPackage` in
`./pkgs/top-level/dhall-packages.nix`.

The solution is to add a separate `.overridePackage` method which is
essentially the exact same as `.override`, except that it is no
longer clobbered by `callPackage`.  This `.overridePackage` method
allows one to override the arguments supplied to
`buildDhall{Directory,GitHub}Package`, making it easier to specify
package versions outside of the ones supported by Nixpkgs..

This also includes a change to only build one (preferred) version of each
package (instead of multiple supported versions per package), in order to
minimize the maintenance burden for the Dhall package set.
2020-11-11 11:16:04 +01:00
Gabriel Gonzalez
459cf94991 Nixpkgs support for dhall-to-nixpkgs
The motivation for this change is to enable a new Dhall command-line
utility called `dhall-to-nixpkgs` which converts Dhall packages to
buildable Nix packages.  You can think of `dhall-to-nixpkgs` as the
Dhall analog of `cabal2nix`.

You can find the matching pull request for `dhall-to-nixpkgs` here:

https://github.com/dhall-lang/dhall-haskell/pull/1826

The two main changes required to support `dhall-to-nixpkgs` are:

* Two new `buildDhall{Directory,GitHub}Package` utilities are added

  `dhall-to-nixpkgs` uses these in the generated output

* `pkgs.dhallPackages` now selects a default version for each package
  using the `prefer` utility

  All other versions are still buildable via a `passthru` attribute
2020-06-17 15:57:21 +02:00
Gabriel Gonzalez
38f1d70c01 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-11 22:02:53 -08:00