rules_haskell_worker_dependencies necessary

[guibou]

Describe the bug

On a client codebase bazel fetch //... fails with:

The repository '@rules_haskell_worker_dependencies' could not be resolved and referenced by '@rules_haskell//tools/worker:bin'

Note that we are not using the new worker feature.

This is solved by adding the following at the end of our WORKSPACE and providing stack in your build environment:

# For rules_haskell persistent worker (tools/worker)
load("@rules_haskell//tools:repositories.bzl", "rules_haskell_worker_dependencies")

rules_haskell_worker_dependencies()

To Reproduce

bazel fetch //... in a bazel workspace which does not call rules_haskell_worker_dependencies.

Expected behavior

• The rules_haskell_worker_dependencies call should not be mandatory if the feature is not used
• The error message may be more detailled
• stack should not be mandatory if stack features are not used.

[ulysses4ever]

I have no clear vision as to how to fix this. The only idea I have is adding select to the deps, which would make deps empty if the worker flag is not passed. I might have time to try it out later in the week.

[aherrmann]

The issue seems to be that bazel fetch does not take configuration into account (same as bazel query). A similar issue is discussed in rules_go here.

As a possible workaround, depending on the use-case, both bazel fetch and bazel query accept a --keep_going flag to ignore such errors. Of course that also hides legitimate errors.

To avoid this error we may have to avoid using select.

[mboes]

Is there an upstream ticket about this in https://github.com/bazelbuild/bazel? @ianthehat mentions that some kind of "no execute" flag might get added to bazel build, but I'm not sure whether that has happened in the intervening two years, or whether there are still plans to do so in the future.

[aherrmann]

@mboes Yes, https://github.com/bazelbuild/bazel/issues/8565 describes the issue that bazel fetch does not take configuration into account. They propose bazel sync as an alternative, @guibou would bazel sync work for your use-case?

Related, https://github.com/bazelbuild/bazel/issues/3246 describes that bazel fetch does not fetch all registered toolchains. Maybe we could work around this issue that way, define a new toolchain for the worker, in non-worker mode it resolves to a dummy toolchain, and in worker mode it resolves to a toolchain that contains the proper worker.

[mboes]

@guibou any word on the question above?

[ulysses4ever]

@guibou any thoughts?

[guibou]

bazel sync fetchs a lot too much and it seems to refetch everything unconditionally, but does not fail.

I've removed bazel fetch from my workflow, so this is not an issue anymore for me.

[Profpatsch]

I guess we can close then? Feel free to reopen.

[guibou]

NOTE: some instances of bazel query may also triggers this behavior. For example: bazel query 'kind(".*haskell_library", allpaths(//..., //...).

[jcpetruzza]

We are running into this issue too. Something as basic as this query will trigger the error:

bazel query 'deps(//some/haskell/binary')'

@guibou's workaround worked for us, but still this issue should probably be reopened.

[robinp]

FYI the build --nobuild mode made available in https://github.com/NixOS/nixpkgs/commit/d7d4a926957de29e8e618d1c848e2036ea98d9cc seems to address shortcomings of fetch.