daml/compatibility/bazel-haskell-deps.bzl

92 lines
2.9 KiB
Python
Raw Normal View History

# Copyright (c) 2022 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
# SPDX-License-Identifier: Apache-2.0
# Defines external Haskell dependencies.
#
# Add Stackage dependencies to the `packages` attribute of the `@stackage`
# `stack_snapshot` in the very bottom of this file. If a package or version is
# not available on Stackage, add it to the custom stack snapshot in
# `stack-snapshot.yaml`. If a library requires patching, then add it as an
# `http_archive` and add it to the `vendored_packages` attribute of
# `stack_snapshot`. Executables are defined in an `http_archive` using
# `haskell_cabal_binary`.
load("@bazel_skylib//lib:dicts.bzl", "dicts")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@os_info//:os_info.bzl", "is_windows")
load("@rules_haskell//haskell:cabal.bzl", "stack_snapshot")
load("@dadew//:dadew.bzl", "dadew_tool_home")
def daml_haskell_deps():
"""Load all Haskell dependencies of the DAML repository."""
use_integer_simple = not is_windows
stack_snapshot(
name = "stackage",
extra_deps = {
"zlib": ["@com_github_madler_zlib//:libz"],
},
stack_snapshot_json =
"//:stackage_snapshot_windows.json" if is_windows else "//:stackage_snapshot.json",
flags = {
"cryptonite": ["-integer-gmp"],
"hashable": ["-integer-gmp"],
"integer-logarithms": ["-integer-gmp"],
"scientific": ["integer-simple"],
"text": ["integer-simple"],
} if use_integer_simple else {},
haddock = False,
local_snapshot = "//:stack-snapshot.yaml",
packages = [
"aeson",
Include puppeteer tests in compat tests (#6018) * Include puppeteer tests in compat tests This PR adds the puppeteer based tests to the compatibility tests. This also means that they are now actually compatibility tests. Before, we only tested the SDK side. Apart from process management being a nightmare on Windows as usually, there are two things that might stick out here: 1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a lengthy comment explaining why. I think at the moment, we could actually get rid of the wraper completely and add JAVA to path in the tests that need it but at least for now, I’d like to keep it until we are sure that we don’t need to add more to it (and then it’s also in the git history if we do need to resurrect it). 2. These tests are duplicated now similar to the `daml ledger *` tests. The reasoning here is different. They depend on the SDK tarball either way so performance wise there is no reason to keep them. However, we reference the other file in the docs which means we cannot change it freely. What we could do is to make this sufficiently flexible to handle both the `daml start` case and separate `daml sandbox`/`daml json-api` processes and then we can reference it in the docs. There is still added complexity for Windows but that’s necessary for users as well that want to run this on Windows so that seems unavoidable. (I should probably also remove my snarky comments :innocent:) I’d like to kee it duplicated for this PR and then we can clean it up afterwards. changelog_begin changelog_end * Bump timeouts changelog_begin changelog_end
2020-05-22 15:02:59 +03:00
"aeson-extra",
"async",
"base",
"bytestring",
"conduit",
"conduit-extra",
"containers",
"cryptonite",
"directory",
"extra",
"filepath",
"http-client",
"http-conduit",
"jwt",
"lens",
"lens-aeson",
"memory",
"monad-loops",
"mtl",
"network",
"optparse-applicative",
"process",
"safe",
"safe-exceptions",
"semver",
"split",
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
"stm",
"tagged",
"tar-conduit",
"tasty",
"tasty-hunit",
"text",
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
"typed-process",
"unix-compat",
"unordered-containers",
Add `platform-version` field to `daml.yaml` (#6736) * Add `platform-version` field to `daml.yaml` This PR adds the `platform-version` field to `daml.yaml`. Based on the approach agreed upon in #6558, the logic for this all sits in `daml-helper` and there are no changes to the assistant. The details of how the logic work are in a comment so I’m not going to repeat them here but the commands that are affected are: - `daml sandbox` - `daml sandbox-classic` - `daml json-api` - `daml start` (but only for sandbox and the JSON API, not for Navigator or anything else) For tests, I’ve added a test to the compat workspace that installs two SDKs simultaneously and tries out various combinations and verifies that we get the correct version. Open to other ideas for testing this but that seemed like the most sensible option that actually tests what we run. changelog_begin - [DAML Assistant] You can now specify the version of Sandbox and the JSON API independently of your SDK version by setting ``platform-version`` in your ``daml.yaml``. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details. changelog_end * Run platform-version tests changelog_begin changelog_end * Fix tag globbing changelog_begin changelog_end * fmt changelog_begin changelog_end * . changelog_begin changelog_end * Try to fix env vars changelog_begin changelog_end * Remove hardcoded references to 1.2.0 changelog_begin changelog_end * Rephrase doc comment changelog_begin changelog_end * get things to compile changelog_begin changelog_end * maybe fix things for realz changelog_begin changelog_end * Remove debugging output changelog_begin changelog_end * Get angry at windows changelog_begin changelog_end * why is windows changelog_begin changelog_end * . changelog_begin changelog_end
2020-07-15 17:30:01 +03:00
"utf8-string",
"uuid",
],
stack = "@stack_windows//:stack.exe" if is_windows else None,
)
if is_windows:
native.new_local_repository(
name = "stack_windows",
build_file_content = """
exports_files(["stack.exe"], visibility = ["//visibility:public"])
""",
path = dadew_tool_home("stack"),
)