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

Use custom repo rule to generate @scalafmt_default #1626

Merged

Conversation

mbland
Copy link
Contributor

@mbland mbland commented Oct 18, 2024

Description

Replaces native.new_local_repository in scalafmt_default_config with the new scalafmt_config repo rule. Also updates the native.register_toolchains call with a stringified Label to remove the hardcoding of @io_bazel_rules_scala.

Resolves an incompatibility between Bazel 6.5.0 and 7.3.2, while creating a much smaller @scalafmt_default repo. The problem is that under Bazel 7.3.2, calling scalafmt_default_config from a module extension produces this error:

$ bazel test //test/scalafmt/...

ERROR: Traceback (most recent call last):
  File ".../scala/extensions/deps.bzl",
    line 218, column 32, in _scala_deps_impl
    scalafmt_default_config()
  File ".../scala/scalafmt/scalafmt_repositories.bzl",
    line 18, column 32, in scalafmt_default_config
    native.new_local_repository(

Error in new_local_repository: The native module can be accessed only
  from a BUILD thread. Wrap the function in a macro and call it from a
  BUILD file

Ostensibly the solution is to replace native.new_local_repository with:

load(
  "@bazel_tools//tools/build_defs/repo:local.bzl",
  "new_local_repository",
)

However, local.bzl isn't available in Bazel 6.5.0:

$ bazel test //test/scalafmt/...

ERROR: Error computing the main repository mapping:
  at .../scala/scalafmt/scalafmt_repositories.bzl:8:6:
cannot load '@bazel_tools//tools/build_defs/repo:local.bzl':
  no such file

The new scalafmt_config repository rule works under both Bazel 6.5.0 and 7.3.2, WORKSPACE and Bzlmod. Also, it symlinks only the single Scalafmt config file, instead of every top level file and directory in the project, as new_local_repository did.

Motivation

Part of the Bzlmodification effort from #1482, to make scalafmt_default_config compatible with both WORKSPACE and MODULE.bazel under both Bazel 6 and 7.

Also, removing instances of @io_bazel_rules_scala with Labels reduces the project's dependency on this name. Bzlmod consumers will then be able to call bazel_dep(name = "rules_scala", ...) without having to set repo_name = "io_bazel_rules_scala".

Part of bazelbuild#1482.

Replaces `native.new_local_repository` in `scalafmt_default_config` with
the new `scalafmt_config` repo rule. Resolves an incompatibility between
Bazel 6.5.0 and 7.3.2, while creating a much smaller `@scalafmt_default`
repo. Also updates the `native.register_toolchains` call with a
stringified `Label` to remove the hardcoding of `@io_bazel_rules_scala`.

The problem is that under Bazel 7.3.2, calling `scalafmt_default_config`
from a module extension produces this error:

```txt
$ bazel test //test/scalafmt/...

ERROR: Traceback (most recent call last):
  File ".../scala/extensions/deps.bzl",
    line 218, column 32, in _scala_deps_impl
    scalafmt_default_config()
  File ".../scala/scalafmt/scalafmt_repositories.bzl",
    line 18, column 32, in scalafmt_default_config
    native.new_local_repository(

Error in new_local_repository: The native module can be accessed only
  from a BUILD thread. Wrap the function in a macro and call it from a
  BUILD file
```

Ostensibly the solution is to replace `native.new_local_repository`
with:

```py
load(
  "@bazel_tools//tools/build_defs/repo:local.bzl",
  "new_local_repository",
)
```

However, `local.bzl` isn't available in Bazel 6.5.0:

```txt
$ bazel test //test/scalafmt/...

ERROR: Error computing the main repository mapping:
  at .../scala/scalafmt/scalafmt_repositories.bzl:8:6:
cannot load '@bazel_tools//tools/build_defs/repo:local.bzl':
  no such file
```

The new `scalafmt_config` repository rule works under both Bazel 6.5.0
and 7.3.2. Also, it symlinks only the single Scalafmt config file,
instead of every top level file and directory in the project, as
`new_local_repository` did.
@mbland mbland force-pushed the bzlmod-update-scalafmt-default-config branch from 89bdc20 to 3f9df30 Compare October 21, 2024 15:02
@mbland
Copy link
Contributor Author

mbland commented Oct 21, 2024

Rebased and passing after #1627, including latest Bazel 7.3.2.

@liucijus liucijus merged commit fa7c661 into bazelbuild:master Oct 23, 2024
2 checks passed
@mbland mbland deleted the bzlmod-update-scalafmt-default-config branch October 23, 2024 14:13
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

Successfully merging this pull request may close these issues.

3 participants