You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The naming of the stack_snapshot generated external workspace for executable targets interacts badly with bzlmod name mapping.
rules_haskell's stack_snapshot module extension generates a main workspace for library targets named stackage and a secondary workspace exposing executable components using the same name with an -exe suffix, i.e. stackage-exe. To use third-party libraries or tools a user must invoke use_repo(stack_snapshot, "stackage", "stackage-exe"). So far, so good.
However, the stack_snapshot module extension always uses the external workspace names stackage and stackage-exe, instead of accepting a name attribute, see tweag/rules_haskell#1962 and bazel-contrib/rules-template#46 (comment) for motivation. So, we must use repo name mapping to avoid name collision with the main stackage workspace. But, for module extension generated external workspaces repo name mapping is declared using keyword argument syntax on the use_repo function, e.g. use_repo(stack_snapshot_b, stackage_b = "stackage").
That means that the target workspace name must be a valid Starlark identifier. To my knowledge there is no way to construct a valid identifier equaling stackage-b or stackage-b-exe. So, instead we would have to fall back to a syntax like stackage_b and stackage_b_exe. However, Gazelle Cabal can currently only be configured in the main workspace name and hard-codes a -exe suffix for the executables workspace (e.g. here and elsewhere). This is incompatible with bzlmod repo name remapping.
To Reproduce
Try to run the alternative-deps tests with bzlmod enabled as of commit 086fffe.
Expected behavior
It should be possible to apply bzlmod repo renaming to a stackage snapshot and still access both the main library workspace and the executables workspace.
Don't use dashes, instead generate stackage and stackage_exe in stack_snapshot.
Add a name attribute to the stack_snapshot extension. This doesn't really fix the remapping issue, but rather just provides a different channel to control the name. Name attributes are preferably avoided as discussed in chore: add bzlmod bazel-contrib/rules-template#46 (comment). Though, in the special case of isolate = True modules they would not be problematic.
Make both the main and the executables workspace names separately configurable in Gazelle Cabal. Given that use_repo allows independently remapping these names, this could be seen as necessary.
Describe the bug
The naming of the
stack_snapshot
generated external workspace for executable targets interacts badly with bzlmod name mapping.rules_haskell's
stack_snapshot
module extension generates a main workspace for library targets namedstackage
and a secondary workspace exposing executable components using the same name with an-exe
suffix, i.e.stackage-exe
. To use third-party libraries or tools a user must invokeuse_repo(stack_snapshot, "stackage", "stackage-exe")
. So far, so good.Now let's say that a user wants to import a secondary Stack snapshot, e.g.
stackage-b
as illustrated in thegazelle_cabal
test suite. To translate this use-case to bzlmod we can use an isolated extension.However, the
stack_snapshot
module extension always uses the external workspace namesstackage
andstackage-exe
, instead of accepting a name attribute, see tweag/rules_haskell#1962 and bazel-contrib/rules-template#46 (comment) for motivation. So, we must use repo name mapping to avoid name collision with the mainstackage
workspace. But, for module extension generated external workspaces repo name mapping is declared using keyword argument syntax on theuse_repo
function, e.g.use_repo(stack_snapshot_b, stackage_b = "stackage")
.That means that the target workspace name must be a valid Starlark identifier. To my knowledge there is no way to construct a valid identifier equaling
stackage-b
orstackage-b-exe
. So, instead we would have to fall back to a syntax likestackage_b
andstackage_b_exe
. However, Gazelle Cabal can currently only be configured in the main workspace name and hard-codes a-exe
suffix for the executables workspace (e.g. here and elsewhere). This is incompatible with bzlmod repo name remapping.To Reproduce
Try to run the
alternative-deps
tests with bzlmod enabled as of commit 086fffe.Expected behavior
It should be possible to apply bzlmod repo renaming to a stackage snapshot and still access both the main library workspace and the executables workspace.
Environment
Additional context
Bazel Slack discussion.
The text was updated successfully, but these errors were encountered: