{"id":19783703,"url":"https://github.com/intersectmbo/cardano-haskell-packages","last_synced_at":"2025-04-30T22:31:41.423Z","repository":{"id":57887500,"uuid":"527735453","full_name":"IntersectMBO/cardano-haskell-packages","owner":"IntersectMBO","description":"Metadata for Cardano's Haskell package repository","archived":false,"fork":false,"pushed_at":"2025-04-27T00:28:12.000Z","size":417043,"stargazers_count":34,"open_issues_count":36,"forks_count":30,"subscribers_count":52,"default_branch":"main","last_synced_at":"2025-04-27T01:25:46.299Z","etag":null,"topics":["cardano","haskell","nix"],"latest_commit_sha":null,"homepage":"https://chap.intersectmbo.org/","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/IntersectMBO.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE-OF-CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2022-08-22T21:19:53.000Z","updated_at":"2025-04-25T18:40:55.000Z","dependencies_parsed_at":"2023-09-27T19:35:37.988Z","dependency_job_id":"ae159992-4659-4dd2-be5b-845bfd0d1808","html_url":"https://github.com/IntersectMBO/cardano-haskell-packages","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IntersectMBO%2Fcardano-haskell-packages","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IntersectMBO%2Fcardano-haskell-packages/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IntersectMBO%2Fcardano-haskell-packages/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/IntersectMBO%2Fcardano-haskell-packages/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/IntersectMBO","download_url":"https://codeload.github.com/IntersectMBO/cardano-haskell-packages/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251791635,"owners_count":21644434,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cardano","haskell","nix"],"created_at":"2024-11-12T06:09:02.366Z","updated_at":"2025-04-30T22:31:39.932Z","avatar_url":"https://github.com/IntersectMBO.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Cardano Haskell package repository (\"CHaP\")\n\n* [All packages](https://chap.intersectmbo.org/all-packages/).\n* [All package versions](https://chap.intersectmbo.org/all-package-versions/).\n\n*Top How-Tos*\n\n* [Adding a package from GitHub](#-from-github)\n* [Making a metadata revision of an already-released package version](#how-to-add-a-new-package-metadata-revision)\n* [Adding a patched version of a Hackage package](#how-to-add-a-patched-versions-of-a-hackage-package)\n\nThis is a Cabal package repository (\"CHaP\") whose purpose is to contain all the Haskell\npackages used by the Cardano open-source project which are not on Hackage.\n\nThe package repository itself is available [here](https://chap.intersectmbo.org).\nIt is built from a [git repository](https://github.com/intersectmbo/cardano-haskell-packages) which\ncontains the metadata specifying all the package versions. The package repository is built using\n[`foliage`](https://github.com/andreabedini/foliage).\n\n## Help!\n\nIf you have trouble, open an issue, or contact the trustees: @intersectmbo/cardano-haskell-packages-trustees\n\n## Background\n\nThis section explains some concepts that are useful for understanding and working with CHaP.\n\n### What is a Cabal package repository?\n\nA package repository is essentially a mapping from package name and version\nto the source distribution for the package. Most Haskell programmers will be\nfamiliar with the package repository hosted on Hackage, which is enabled\nby default in Cabal.\n\nHowever, Cabal supports the use of _additional_ package repositories.\nThis is convenient for users who can't or don't want to put their packages\non Hackage.\n\n### Cabal package repositories and `source-repository-package`\n\nUsing `source-repository-package` stanzas is another common way of getting dependencies\nthat are not on Hackage. Both have their place: CHaP gives us proper versioning\nand simpler setup, `source-repository-package`s are useful for ad-hoc use of\npatched or pre-release versions.\n\nCrucially, additional Cabal package repositories like CHaP and `source-repository-package`\nstanzas are _compatible_ and _`source-repository-package`s always win_. That is,\nthey interact in the same way as Hackage and `source-repository-package`s do. This gives us\nbehaviour that we want: ad-hoc `source-repository-package` stanzas will override\npackages from Hackage _or_ CHaP.\n\n## Using CHaP\n\nTo use CHaP with cabal, add the following lines to your\n`cabal.project` file:\n\n```\nrepository cardano-haskell-packages\n  url: https://chap.intersectmbo.org/\n  secure: True\n  root-keys:\n    3e0cce471cf09815f930210f7827266fd09045445d65923e6d0238a6cd15126f\n    443abb7fb497a134c343faf52f0b659bd7999bc06b7f63fa76dc99d631f9bea1\n    a86a1f6ce86c449c46666bda44268677abf29b5b2d2eb5ec7af903ec2f117a82\n    bcec67e8e99cabfa7764d75ad9b158d72bfacf70ca1d0ec8bc6b4406d1bf8413\n    c00aae8461a256275598500ea0e187588c35a5d5d7454fb57eac18d9edb86a56\n    d4a35cd3121aa00d18544bb0ac01c3e1691d618f462c46129271bccf39f7e8ee\n```\n\nThe package repository will be understood by cabal, and can be updated with `cabal update`.\nYou must run `cabal update` at least once so cabal can download the package index!\n\nThe `index-state` for the package repository can also be pinned as usual.\nYou can either just use a single `index-state` for both Hackage and CHaP:\n\n```\nindex-state: 2022-08-25T00:00:00Z\n```\n\nor you can specify a different index-state for each repository:\n\n```\nindex-state:\n  , hackage.haskell.org      2022-12-31T00:00:00Z\n  , cardano-haskell-packages 2022-08-25T00:00:00Z\n```\n\nNote that a second `index-state` stanza completely ovverides the first, so\n\n```\nindex-state: 2022-12-31T00:00:00Z\nindex-state: cardano-haskell-packages 2022-08-25T00:00:00Z\n```\n\nwould override the index-state for Hackage to HEAD (since HEAD is the default).\n\n### ... with haskell.nix\n\nTo use CHaP with `haskell.nix`, do the following:\n\n1. Add the package repository to your `cabal.project` as above.\n2. Setup a fetcher for the package repository. The easiest way is to use a flake input, such as:\n```\ninputs.CHaP = {\n  url = \"github:intersectmbo/cardano-haskell-packages?ref=repo\";\n  flake = false;\n};\n```\n3. Tell haskell-nix to map the CHaP url to the appropriate nix store path using the `inputMap` argument of one of [haskell.nix project functions](https://input-output-hk.github.io/haskell.nix/reference/library.html#top-level-attributes). Using `cabalProject` this would look like the following:\n```\ncabalProject {\n  ...\n  inputMap = { \"https://chap.intersectmbo.org/\" = CHaP; };\n}\n```\n\nTo build some of the pacakges from CHaP, some C libraries will need to be installed. If you don't have those libraries installed cabal may pick an older library version that might not compile. An easy way to add those libraries is using the overlays provided by [iohk-nix](https://github.com/input-output-hk/iohk-nix). For example `plutus-core==1.21.0.0` depends on `libblst`, `haskell-nix-crypto` and `crypto` are the two overlays that would make it available during the build.\n\nWhen you want to update the state of CHaP, you can simply update the flake input\n(in the example above you would run `nix flake lock --update-input CHaP`).\n\nIf you have CHaP configured correctly, then when you run `cabal build` from inside a `haskell.nix`\nshell, you should not see any of the packages in CHaP being built by cabal.\nThe exception is if you have a `source-repository-package` stanza which overrides a _dependency_ of one\nof the packages in CHaP. Then cabal will rebuild them both. If this becomes a problem,\nyou can consider adding the patched package to CHaP itself,\nsee [below](#how-do-i-add-a-patched-versions-of-a-hackage-package-to-chap).\n\n### Updating dependencies from CHaP\n\nIf you have a Haskell project which has bounds on CHaP packages, we provide a script which will update all of those bounds to\npin the latest major version of each that is released to CHaP.\n\nYou can run it like so: `nix run --update-input CHaP --no-write-lock-file \"github:intersectmbo/cardano-haskell-packages#update-chap-deps\" pkgA pkgB`.\nThis will update the bounds for everything from CHaP, except for those on `pkgA` or `pkgB`. This lets you blacklist packages\nthat you don't want to update (e.g. because you know that the update will break you, or it's your own package!).\n\n### Creating a repository like CHaP\n\nIf you just want to test changes to CHaP, you should make a\nfork. If you want to replicate the setup from scratch you can clone [this template](https://github.com/andreabedini/foliage-template).\n\n## Contributing packages and revisions\n\nThis section explains how to contribute to the main content of CHaP: packages and revisions.\nThe contribution itself should be [made in a PR](#making-changes).\n\n### Requirements for including a package\n\n#### Monotonically increasing timestamps\n\nWhen adding a package, it is important to use a timestamp (see [below](#how-to-add-a-new-package-version))\nthat is greater than any other timestamp in the index. Indeed, cabal users rely on\nthe changes to the repository index to be append-only. A non append-only\nchange to the package index would change the repository index state as\npinned by `index-state`, breaking reproducibility.\n\nThis condition is enforced by the CI, and we only allow FF-merges in order to ensure that we are always checking a linear history.\n\nTips for working with timestamps:\n- Most of the scripts will insert timestamps for you, e.g. `./scripts/add-from-github.sh`\n- If you have a PR and the timestamps are now too old (e.g. because someone else made a PR in the meantime), then see [below](#dealing-with-timestamp-conflicts) for tips\n- If you want to get a suitable timestamp for some other reason, `./scripts/current-timestamp.sh` will produce one\n\n#### No extra build configuration beyond what is given in the cabal file\n\nWhen downstream users pull a package from CHaP, `cabal` will build it based _only_ on the\ninformation in the cabal file. This means that if your package needs any additional configuration\nto build, then it will simply be broken for downstream users unless they replicate that\nconfiguration.\n\nTypical examples of this are anything that you add in `cabal.project`:\n- `constraints`\n- `allow-newer`\n- `source-repository-package`\n\nThis is enforced by the CI, which will build newly added packages in PRs.\n\n### How to add a new package version\n\nPackage versions are defined using metadata files `_sources/$pkg_name/$pkg_version/meta.toml`,\nwhich you can create directly. The metadata files have the following format:\n\n```toml\n# REQUIRED timestamp at which the package appears in the index\ntimestamp = 2022-03-29T06:19:50+00:00\n# REQUIRED URL pointing to the source code tarball (not necessarily a sdist)\nurl = 'https://github.com/intersectmbo/ouroboros-network/tarball/fa10cb4eef1e7d3e095cec3c2bb1210774b7e5fa'\n# OPTIONAL subdirectory inside the tarball where the package is located\nsubdir = 'typed-protocols'\n```\n\n#### ... from GitHub\n\nThere is a convenience script `./scripts/add-from-github.sh` to simplify\nadding a package from a GitHub repository.\n\n```console\n$ ./scripts/add-from-github.sh\nUsage add-from-github.sh [-f OVERWRITE_VERSION] REPO_URL COMMIT-SHA [SUBDIRS...]\n\n        -f OVERWRITE_VERSION      (DANGEROUS) uses OVERWRITE_VERSION as the package version instead of the one from the tarball\n        REPO_URL                  the repository's Github URL\n        COMMIT_SHA                the commit SHA for the package source\n        SUBDIRS                   the list of relevant sub-directories\n```\n\nFor example, to add a new version from `plutus`'s `plutus-core` and `plutus-ledger-api`, etc from commit `75267027f157f1312964e7126280920d1245c52d`, run\n\n```console\n./scripts/add-from-github.sh \"https://github.com/intersectmbo/plutus\" 75267027f157f1312964e7126280920d1245c52d plutus-core plutus-ledger-api plutus-tx plutus-tx-plugin prettyprinter-configurable\n```\n\nThe script will:\n\n1. Find the cabal files in the repo (either at the root or in the specified subdirectories)\n2. Obtain package names and versions from the cabal files\n3. Create the corresponding `meta.toml` files\n4. Commit the changes to the git repository\n\nYou can tell the script to override the package version either by passing\nthe version explicitly or by adding a \"revision number\" (see below).\n\n### How to add a new package metadata revision\n\nCHaP supports package metadata revisions just like Hackage. These allow you to provide an edited cabal\nfile for a package version. The primary use of this is to tweak the dependency bounds of a package.\nIn principle you can change other things too, but this is generally frowned upon.\n\nThis repository contains a convenience script for adding a revision to CHaP:\n```\n$ ./scripts/add-revision.sh _repo PACKAGE_NAME PACKAGE_VERSION\n```\n\n`_repo` needs to point to a [built package repository](#how-to-get-the-built-cabal-package-repository).\nIt will add a new revision and copy the _current_ cabal file in as the revised cabal file.\nYou can then edit that file and commit the result.\n\n### How to deprecate a package\n\nCHaP supports package version deprecations just like Hackage. \nThese allow you to make a package \"not-preferred\" by the cabal solver (note that the solver will still pick a deprecated package version if it cannot pick a non-deprecated one).\n\nThere is not currently a script for adding a deprecation, but you can find examples by serarching for \"deprecations\" in the repository.\nDeprecations must include a timestamp (like all events) and indicate the new deprecation state (so package versions can also be un-deprecated).\n\n### How to add a patched versions of a Hackage package\n\nCHaP should mostly contain versions of packages which are _not_ on Hackage.\n\nIf you need to patch a version of a package on Hackage, then there are two options:\n\n1. For short lived forks, use a `source-repository-package` stanza by preference.\n2. For long-lived forks (because e.g. the maintainer is unresponsive or the patch is large and will take time to upstream), then we can consider releasing a patched version in CHaP.\n\nThe main constraint when adding a patched version to CHaP is to be sure that we use a version number that won't ever conflict with a release made by upstream on Hackage.\nThere are two approaches to doing this:\n\n1. Release the package in CHaP under a different name (for the fork).\nThis is very safe, but may not be possible if the dependency is incurred via a package we don't control, as then we can't force it to depend on the renamed package.\n2. Release the package under a version that is very unlikely to be used by upstream.\nThe scheme that we typically use is to take the existing version number, add four zero components and then a patch version, e.g. `1.2.3.4.0.0.0.0.1`.\n\nIMPORTANT: if you release a patched package to CHaP, make sure to open an issue about it so we can keep track of which patched packages we have.\nIdeally, include the conditions under which we can deprecate it, e.g. \"can deprecate either when it's fixed upstream or when package X removes their dependency on it\".\n\n### How to update Hackage index used by CHaP\n\nIf one of your packages requires a newer version of a package published on Hackage, you will need to run: `nix flake lock --update-input hackage-nix`.\n[`hackage.nix`] is automatically updated from Hackage once per day.\nIf things still don't work because the version of the package is not available you'll need either wait for the automatic update or make a PR to [`hackage.nix`] first and then rerun the above command.\n\n### Releasing CHaP packages to Hackage\n\nIt's totally fine to release a package in CHaP to Hackage.\nThe thing to avoid is to have the same package _version_ in both repositories.\nThe simplest solution is to just make sure to use a higher major version number when you start releasing to Hackage, even if this looks a bit odd.\nFor example, if CHaP contains `X-1.0` and `X-1.1`, then the first Hackage release should be `X-1.2` or `X-2.0`.\n\n## Building and testing CHaP\n\nFor most contributors this section is not going to be necessary, and you can rely on the CI.\n\nHowever if you are making a large number of changes (e.g. many revisions), it can be useful to test your work before making a PR.\n\n### How to get the built Cabal package repository\n\nThe Cabal package repository itself is built using the tool `foliage`.\nYou can either fetch the latest version which is stored in git; or build it yourself locally, which can be convenient or necessary if you have local changes.\n\n#### ... by downloading it from Github\n\nThe built repository is stored in the `repo` branch of CHaP itself.\nYou can get the contents of the `repo` branch from Github at https://github.com/intersectmbo/cardano-haskell-packages/archive/refs/heads/repo.zip .\n\nOr you can check out that branch and copy the contents, e.g.\n```\ngit checkout repo\ngit merge --ff-only\ncp -aR . _repo\ngit checkout -\n```\n\nYou can also check it out as a worktree:\n\n```\ngit worktree add _repo repo\n```\n\nWhen using this later, remember to pull before creating a revision.\n\n#### ... by building it locally\n\n`foliage` is available in the Nix dev shell, which you can get into using `nix develop`.\n\nTo build the repository, run `foliage build -j 0 --write-metadata`. This will build the repository and put it in `_repo`.\n\n### How to test changes\n\nSometimes it is useful to test in advance how a new package or a cabal file\nrevision affects things.\n\nFirst of all, [build the repository](#how-to-build-the-cabal-package-repository).\nFor the rest of this section we will assume the built repository is in\n`/home/user/cardano-haskell-packages/_repo`.\n\n#### ... by building packages with `cabal`\n\nYou can test a locally built CHaP with a small test project consisting of just a\n`cabal.project` file:\n\n```\n-- Give it a different name to avoid cabal confusing it with the\n-- real CHaP\nrepository cardano-haskell-packages-local\n  -- Point this to the *built* repository\n  url: file:/home/user/cardano-haskell-packages/_repo\n  secure: True\n  -- You can skip the root-keys field\n\n-- Add all the packages you want to try building\nextra-packages:\n  , cardano-prelude-0.1.0.0\n```\n\nYou need to tell cabal about the new repository with `cabal update` (you might need to\nclear out `~/.cabal/packages/cardano-haskell-packages-local` if  you've been\nediting your repository destructively).\n\nThen you can build whatever package version you want with `cabal`:\n\n```bash\n$ cabal build cardano-prelude\n```\n\nYou can troubleshoot a failed build plan using the cabal flags `--constraint`, `--allow-newer` and `--allow-older`. Once you have obtained a working build plan, you should revise you cabal file with appropriate constraints.\n\n#### ... by building packages with Nix\n\nYou can build packages from CHaP using Nix like this:\n\n```\nnix build\n  --override-input CHaP path:/home/user/cardano-haskell-packages/_repo\n  '.#\"ghc92/plutus-core/1.1.0.0\"'\n```\n(Note the added quotes around `.#\"ghc92/plutus-core/1.1.0.0\"`.\nFor other shells than `bash` this is required to make sure that the above command works.\nSee: https://github.com/NixOS/nix/issues/4686.\nFor `bash`, the quotes can be omitted.)\n\nThis will build all the components of that package version that CHaP cares about, namely libraries and executables (test suites and benchmarks are not built).\n\nWe need to use `--override-input` because the CHaP flake relies on a built repository.\nBy default it points to a built repository on the main CHaP `repo` branch.\nBut if you have just produced your own built repository (see above) then you want to\nuse that instead, and `--override-input` will let you do that.\n\n#### ... by testing against a haskell.nix project\n\nIf you want to test a locally built CHaP against a project that uses CHaP\nvia haskell.nix, you can build the project while overriding CHaP\nwith your local version.\n\n```bash\n$ nix build --override-input CHaP path:/home/user/cardano-haskell-packages/_repo\n```\n\nNote that you will need to change the `index-state` for `cardano-haskell-packages`\nto be newer than the repository you just built, otherwise cabal will ignore your\nnew package versions!\n\nAlso, you you can examine the build plan without completing the build:\n```bash\n$ nix build .#project.plan-nix.json \\\n\t--out-link plan.json \\\n\t--override-input CHaP path:/home/user/cardano-haskell-packages/_repo\n```\n\nThis is useful if you just want to see whether cabal is able to successfully\nresolve dependencies and see what versions it picked.\n\n## Making changes\n\nChanges to CHaP should simply be made using PRs.\n\n### Access control\n\nCHaP uses `CODEOWNERS` to determine whose approval is needed to release a package.\nThe general rules are:\n\n- If a package is clearly owned by a particular team, then set that team as the CODEOWNER.\n- Prefer to use GitHub teams over individual accounts wherever possible.\n- In the case of patched packages, the owner should be whichever team owns the package that causes the dependency on the package that needs patching.\n\nGenerally, use your judgement about what's appropriate.\n\n### CI\n\nThe CI for CHaP does the following things:\n\n- Checks that the timestamps in the git repository are monotonically increasing through commits.\nAlong with requiring linear history, this ensures that package repository that we build is always an extension of the previous one.\n- Builds the package repository from the metadata using `foliage`.\n- Builds a small set of packages using the newly built repository.\n    - We build with all the major GHC versions we expect to be in use.\n    - At the moment we don't build all the packages in the repository, only the latest versions of a fixed set.\n    - This happens twice, without Haddock and with Haddock.\n- Builds any newly added packages using the newly built repository.\n    - This happens twice, without Haddock and with Haddock.\n- If on the master branch, deploys the package repository to the `repo` branch, along with some static web content.\n\n#### Troubleshooting CI / GitHub Actions\n\nIn case the `build-packages` or `build-new-packages` actions fail, you can retrieve the `built-repo` Artifact from the Actions Summary page for the failed action. Then, unpack it into the `_repo` directory and proceed with the remaining steps in the [CI.yml GitHub Workflow file](.github/workflows/CI.yml). Note that the nixbuild flags are not relevant for reproducing the issue locally and can be ignored.\n\n### Dealing with timestamp conflicts\n\nSince we require monotonically increasing timestamps, there can be timestamp conflicts if someone else merges a PR with later timestamps than yours.\nThat means that your PR (once updated from `main`) will now introduce \"old\" timestamps, which is not allowed.\n\nThere are some scripts for dealing with this:\n- `./scripts/update-timestamps-in-revision.sh REV` will look at the given revision, find any timestamps that were added in that commit, and make changes to update them to a fresh timestamp.\n- `./scripts/update-timestamps-and-fixup.sh REV` will do the same but also commit the changes as a fixup commit. You can either leave these in your PR or get rid of them with `git rebase main --autosquash`\n\nAn easy way to run `update-timestamps-and-fixup` on a multi-commit PR is to run `git rebase main --exec \"./scripts/update-timestamps-and-fixup.sh HEAD\"`.\nThis will run the script at every step of the rebase on `HEAD` (i.e. the commit you have reached).\n\n### Debugging solver issues\n\nSometimes you may hit issues that are related to cabal's constraint solver making strange choices.\nFor example, you are making a PR to release `foo-X`, which depends on `bar` via `baz`.\nBut when the CI builds the package, instead of using the newest `bar-Y`, cabal inexplicably decides to build a very old verison of `bar` that either a) leads to solver errors; or b) leads to compilation errors.\n\nThe root cause is usually that the solver can't pick the version of `bar` that you want because it conflicts with your dependencies in some way, but it is often not obvious why.\nIt's tricky to diagnose, since you'll sometimes want to rebuild the repository to add revisions while you're working.\n\nThe easiest way is to build the package in question [with nix](#-by-building-packages-with-nix), i.e. something like this:\n```\n# repeat this whenever you change the repository, e.g. by adding a revision\n\u003e foliage build -j 0 --write-metadata\n\u003e nix build\n  --override-input CHaP path:/home/user/cardano-haskell-packages/_repo\n  '.#\"ghc92/foo/X\"'\n```\n\nThere are then two ways to make progress:\n1. Add a constraint to force the good case. If you are expecting to build with `bar-Y`, you can add a `bar == Y` constraint and the solver should tell you why it's impossible! You can either add this to the `cabal.project` specified in `nix/builder.nix`, or add `.addConstraint \"bar == Y\"` to the nix invocation. For example: \n```bash\nnix build $(nix eval --raw '.#\"ghc8107/cardano-ledger-core/0.1.0.0\"' \\\n    --apply 'd: (d.passthru.addConstraint \"cardano-crypto-class \u003c2.0.0.1, cardano-binary\u003c1.5.0.1\").drvPath')\n```\n2. Make a revision to rule out the bad case. If your build fails because `baz-Z` can't build with `bar-P`, then `baz-Z` _should_ have a constraint that excludes `bar-P`. You can add this constraint by making a revision to `baz-Z` and try again.\n\nBoth of these should get you to a _different_ error.\nThe advantage of adding constraints is that it tends to more directly reveal the problem as it focusses on what you want to happen.\nThe advantage of the revision is that it permanently records the incompatibility information, which is useful for future people.\n\n[`hackage.nix`]: https://github.com/input-output-hk/hackage.nix\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fintersectmbo%2Fcardano-haskell-packages","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fintersectmbo%2Fcardano-haskell-packages","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fintersectmbo%2Fcardano-haskell-packages/lists"}