Gergely Fábián
Gergely Fábián
> Starting from Bazel 7, the default download mode will be changed from --remote_download_all to --remote_download_toplevel. That is, Bazel will no longer download intermediate outputs of remote actions into the...
The information I received on the Bazel slack was that if rules_scala emitted correct information (`DefaultInfo(runfiles = ...)`) for the outputs it generates (the `.fmt.output` files), then those should be...
The current state where I'm at is this. `phase_scalafmt` seems to be adding the proper information (on the line you quoted): ``` # Return a depset containing all the relevant...
Debug output like this: ``` DEBUG: /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/io_bazel_rules_scala/scala/private/phases/phase_default_info.bzl:38:10: Returning DefaultInfo with runfiles: depset([, , , , , , , , , , ]) DEBUG: /home/user/.cache/bazel/_bazel_user/64527517dacf7170f7d914889f83481c/external/io_bazel_rules_scala/scala/private/phases/api.bzl:85:22: Detected external providers: {"DefaultInfo": struct(data_runfiles =...
Btw. the following command also fails for Bazel 6.4.0: `bazel run --remote_download_toplevel //example-maven:example-maven.format-test`
Maybe the necessary information is lost here: ``` print("DefaultInfo with runfiles: %s" % depset(direct = direct, transitive = runfiles)) print("DefaultInfo runfiles after wrapping: %s" % ctx.runfiles(transitive_files = depset(direct = direct,...
I'm wondering whether `collect_data` does what we expect it to do, especially if I read the comment: https://github.com/bazelbuild/rules_scala/blob/master/scala/private/phases/phase_default_info.bzl#L43-L46
I've added some more debugging and I think api.bzl is returning proper DefaultInfo for the rules. Having https://github.com/bazelbuild/rules_scala/blob/master/scala/private/phases/api.bzl#L91 (that sets up the final rule output): I have added a debug...
Opened Bazel bug: https://github.com/bazelbuild/bazel/issues/20099
Quoting a response from the bazel issue: > There are a couple of odd things going on here, and I'm not sure that any of them are Bazel's fault. >...