The "builtins.fetchTarball" function is not available in some restricted
environments such as build jobs of the latest Hydra. Make it possible to
pass nixpkgs and nixpkgsStaticLinux when evaulating default.nix and
release.nix to avoid importing them internally. This does not change the
result of evaulation if no parameters are passed.
* Allow customization of remote import resolution
Makes the `Status` type more general; previously support for
`Network.HTTP.Client` was hardcoded. In short:
```
data Status = Status
{ _stack :: NonEmpty Chained
[...]
-- , _manager :: Maybe Dynamic
-- -- importing the same expression twice with different values
++ , _remote :: URL -> StateT Status IO Data.Text.Text
++ -- ^ The remote resolver, fetches the content at the given URL.
[...]
}
```
* Simplify and expose `toHeaders`
`toHeaders` will be needed for mock http testing
* Fix compilation without `with-http` flag
* Fix compilation with `with-http` flag
* Fix tests without `with-http` flag
Implements a mock http client that handles requests to:
- `https://raw.githubusercontent.com/dhall-lang/dhall-lang/master/`
- `https://test.dhall-lang.org/Bool/package.dhall`
- `https://httpbin.org/user-agent`
This allows tests involving remote imports to succeed even when compiled
without the `with-http` flag.
* Build `dhall` with HTTP support compiled out in CI
... to prevent regressions from occurring in the future
This adds three new Nix build products:
* `try-dhall-static` - The static assets for "Try Dhall"
* `try-dhall-server` - A script which serves the static assets for local
debugging
* `tarball-try-dhall` - A tarball of the static assets
This is powered by a new small `dhall-try` package which is also included
in this change.
This adds a GHCJS build for Dhall so that:
* We can build a `try.dhall-lang.org` to try Dhall in the
browser until the PureScript implementation comes online
* We can document how to build `dhall` using GHCJS
* We can verify that new changes to `dhall` or its dependencies
don't break GHCJS support
* CI can build and cache GHCJS-related dependencies
CI was running tests, but they weren't blocking merge because they weren't a
dependency of the `dhall` attribute (which is what gates the GitHub status).
This fixes that by adding `coverage.dhall` as a dependency (which does include
tests). The other builds were not running tests since that is what happens
`coverage` defaults to `false`.
This ensures that all of the `dhall-*` libraries build against
GHC 8.6.1, but still generates tarballs using GHC 8.4.3 and
uses GHC 8.4.3 for development
The motivation for this change is:
* To catch build failures in downstream packages whenever we make a breaking
change to the `dhall` API
* To reduce the amount of work I need in order to cut a release for all of
these packages
* To better share Nix/CI-related logic between the projects
Note that I have not yet migrated `dhall-nix` in. I'm waiting for
https://github.com/dhall-lang/dhall-nix/issues/17 to be fixed since
`dhall-nix` is incompatible with later versions of `megaparsec` due to
`hnix`.
Fixes https://github.com/dhall-lang/dhall-haskell/issues/645
Fixes https://github.com/dhall-lang/dhall-lang/issues/216
This updates the `README` with the following changes:
* Points to the language-agnostic `README` in the `dhall-lang` repository
* Retains only Haskell-specific sections of interest
* Removes the embedded LICENSE now that GitHub auto-recognizes the project
license (#644)
* Changes the Quick Start instructions to use Nix
* Adds instructions for project development using Nix
The latter two points entailed refactors to the Nix logic to simplify the
user experience:
* `default.nix` was moved to `shared.nix` and replaced with a new `default.nix`
that works out-of-the-box with `nix-build`
* There is a new `nix/test-dhall.nix` which users can use to create a
`nix-shell` with Dhall as a dependency
... as requested by @jneira so that Dhall will continue to work as a
dependency of Eta, which is built using GHC 7.10.3
This adds CI support for testing the build against GHC 7.10.3 and also
fixes issues building against that GHC version that were caught in the process
This adds a new `dhall-static` target that builds a fully static `dhall`
executable that can be run on any Linux machine (i.e. it is a relocatable
executable that is completely dependency free). That in turns implies
that even though it is built with Nix it doesn't require that the user
installs Nix to run it (i.e. no dependency on the `/nix/store` or a
Nix installer). Just copy the standalone executable to any Linux machine
and it's good to go.
This based on the following work of @nh2:
* https://github.com/NixOS/nixpkgs/issues/43795
* https://github.com/dhall-lang/dhall-lang/issues/192#issuecomment-406134451
This also bumps the version of `nixpkgs` used for the normal (non-static)
Dhall build to be the closest revision on `nixpkgs` `master` as the one
used by @nh2 in his work. Once that work is merged into `nixpkgs` `master`
then both builds can use the same revision from `nixpkgs` `master`.
* Benchmark Prelude files
* Add issue 108 example
* Some cleaning up
* Remove printing of files
* Add bounds
* Clean cabal formatting
* Add benchmark examples to extra source files
* Add Nix support for benchmarks
* This doesn't (yet) run or build the benchmarks in CI due to the long time
to execute all of them, but this does add them to the `shell.nix` so that
they can be run using local development
Hydra doesn't update a pull request if the derivation hasn't changed
since the last revision (i.e. a cache hit). This change adds a `pwd`
derivation which depends trivially on the current directory to force a
cache miss and status update
The long-term motivation for this change is so that we can eventually use a
separate `attoparsec`-based lexing step to greatly increase parsing speed since
the `trifecta`/`parsers` API doesn't allow tokens other than `Char`.
The secondary motivation for this is that `megaparsec` is a smaller dependency
that is more actively maintained.
Eventually we will want to encourage users to download pre-built executables
from Hydra, but this requires statically linking them so that they have
a smaller footprint. Otherwise users will have to download an entire
GHC installation.