rules_haskell icon indicating copy to clipboard operation
rules_haskell copied to clipboard

Issue when loading `amazonka` from git (nested BUILD.bazel inside of `stack_snapshot` dependency)

Open kozak opened this issue 2 years ago • 1 comments

Describe the bug When trying to install amazonka from git using stack_snapshot I am running into an issue:

ERROR: /home/user/.cache/bazel/_bazel_user/869a83396675f139abf70dd5c93f27e7/external/stackage/BUILD.bazel:244:22: in haskell_cabal_library rule @stackage//:amazonka:
Traceback (most recent call last):
        File "/home/user/.cache/bazel/_bazel_user/869a83396675f139abf70dd5c93f27e7/external/rules_haskell/haskell/cabal.bzl", line 466, column 24, in _haskell_cabal_library_impl
                cabal = _find_cabal(hs, ctx.files.srcs)
        File "/home/user/.cache/bazel/_bazel_user/869a83396675f139abf70dd5c93f27e7/external/rules_haskell/haskell/cabal.bzl", line 102, column 13, in _find_cabal
                fail("A .cabal file was not found in the srcs attribute.")
Error in fail: A .cabal file was not found in the srcs attribute.

This can be fixed for a single build by removing BUILD.bazel file included with amazonka:

rm /home/user/.cache/bazel/_bazel_user/869a83396675f139abf70dd5c93f27e7/external/stackage/amazonka-2.0/BUILD.bazel

I think that bazel shouldn't be processing BUILD.bazel files of dependencies ?

To Reproduce

In your WORKSPACE add a stack_snapshot

stack_snapshot(
    name = "test-stackage",
    packages = [
      "amazonka"
    ],
    local_snapshot = "//:test_snapshot.yaml",
)

and the local snapshot file: test_snapshot.yaml

resolver: lts-18.11
packages:
  - git: https://github.com/brendanhay/amazonka
    commit: 29f1740804abe472bfa3385b7c14a4522f83d2dc
    subdirs: [lib/amazonka, lib/services/amazonka-s3, lib/services/amazonka-sqs]

Try building with:

  • bazel build "@test-stackage//:amazonka"
  • it will fail with Error in fail: A .cabal file was not found in the srcs attribute
  • remove the amazonka build file: rm /home/user/.cache/bazel/_bazel_user/REPLACE_WITH_HASH_FROM_ERROR_MESSAGE/external/test-stackage/amazonka-2.0/BUILD.bazel
  • it should build now

Expected behavior

The package should build without having to remove the nested BUILD.bazel file.

Environment

  • OS name + version: Ubuntu 20.04.4 LTS (Focal Fossa)
  • Bazel version: 5.2.0
  • Version of the rules: rules_haskell-0.15

Additional context Thank you for you amazing work! We are just starting with Bazel / rules haskell so maybe I am missing an obvious solution.

kozak avatar Aug 08 '22 14:08 kozak

Workaround:

stack_snapshot(
      ...
      vendored_packages = {
          "amazonka": "@amazonka//:amazonka",
          "amazonka-s3": "@amazonka-s3//:amazonka-s3",
      }
)


####################
# Vendored packages
####################

http_archive(
    name = "amazonka",
    build_file_content = """
load("@rules_haskell//haskell:cabal.bzl", "haskell_cabal_library")
load("@stackage//:packages.bzl", "packages")
haskell_cabal_library(
  name = "amazonka",
  version = packages["amazonka"].version,
  srcs = glob(["**"]),
  deps = packages["amazonka"].deps,
  visibility = ["//visibility:public"],
)
""",
    strip_prefix = "brendanhay-amazonka-29f1740/lib/amazonka",
    sha256 = "6d68f936150b022209ac5300602a5b74d9acf5e228e7a5cc84e8ba235c30d036",
    type = "tar.gz",
    urls = ["https://github.com/brendanhay/amazonka/tarball/29f1740804abe472bfa3385b7c14a4522f83d2dc"],
)

# Duplicated, but I don't know how to do this differently (haskell_cabal_library depends on the `name` parameter to find
# cabal file), maybe `package_name` ? 

http_archive(
    name = "amazonka-s3",
    build_file_content = """
load("@rules_haskell//haskell:cabal.bzl", "haskell_cabal_library")
load("@stackage//:packages.bzl", "packages")
haskell_cabal_library(
  name = "amazonka-s3",
  version = packages["amazonka-s3"].version,
  srcs = glob(["**"]),
  deps = packages["amazonka-s3"].deps,
  visibility = ["//visibility:public"],
)
""",
    strip_prefix = "brendanhay-amazonka-29f1740/lib/services/amazonka-s3",
    sha256 = "6d68f936150b022209ac5300602a5b74d9acf5e228e7a5cc84e8ba235c30d036",
    type = "tar.gz",
    urls = ["https://github.com/brendanhay/amazonka/tarball/29f1740804abe472bfa3385b7c14a4522f83d2dc"],
)

kozak avatar Aug 09 '22 14:08 kozak

I've also run into this (rules_haskell-0.15 and bazel 4.2.2) and removing the BUILD.bazel also "fixed" the issue.

I am relying on a similar workaround (vendoring amazonka) for now.

jonathanlking avatar Dec 01 '22 15:12 jonathanlking

Thank you for reporting this @kozak!

I think that bazel shouldn't be processing BUILD.bazel files of dependencies ?

That's a tricky issue, unfortunately there's no way to make Bazel generally ignore such BUILD files. There's a relevant discussion on the mailing list going into further details.

However, the flag --deleted_packages may provide an easier workaround. Judging by Bazel's test-suite it should also work for external workspaces. IIUC the correct spelling in this case should be --deleted_packages=@test-stackage//amazonka-2.0.

aherrmann avatar Dec 01 '22 16:12 aherrmann

Thanks for the context/suggestion @aherrmann, in my case running bazel build @stackage//:amazonka-core --deleted_packages=@stackage//amazonka-core-2.0 now works 🎉 (while without the deleted_packages it fails).

Having to set this flag though when calling bazel is a bit cumbersome; I have found setting build --deleted_packages=@stackage//amazonka-core-2.0 in the .bazelrc works, but it makes me uncomfortable that not everything is contained in the file where we call stack_snapshot. (If you go with the vendoring approach, even though there's extra code, it's all encapsulated).

jonathanlking avatar Dec 01 '22 17:12 jonathanlking

@jonathanlking Thank you for testing --deleted_packages and reporting back!

As mentioned before I fear there is not much else we can do about this issue in rules_haskell, so, I'm closing this issue. Two possible workarounds are described in the discussion here: Use the --deleted_packages flag, or patch and vendor the package.

aherrmann avatar Dec 02 '22 08:12 aherrmann