Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack_snapshot -exe suffix incompatible with bzlmod name remapping. #61

Open
aherrmann opened this issue Sep 26, 2023 · 1 comment
Open

Comments

@aherrmann
Copy link
Member

aherrmann commented Sep 26, 2023

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.

Now let's say that a user wants to import a secondary Stack snapshot, e.g. stackage-b as illustrated in the gazelle_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 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.

Environment

  • OS name + version: Ubuntu 22.04
  • Version of the code: 4ca7d2a

Additional context
Bazel Slack discussion.

@aherrmann
Copy link
Member Author

Possible solutions that come to mind:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant