profile
viewpoint
Xùdōng Yáng Wyverald Google Munich, Germany wyverald.me

bazelbuild/bazel-central-registry 31

The central registry of Bazel modules for the Bzlmod external dependency system.

Wyverald/net9-auth 3

The authentication module for net9.

Wyverald/bazel 0

a fast, scalable, multi-language and extensible build system

Wyverald/bazel-website 0

Website for Bazel, a fast, scalable, multi-language and extensible build system

Wyverald/bazelcon 0

Artifacts from BazelCon

Wyverald/bazelisk 0

A user-friendly launcher for Bazel.

Wyverald/core 0

Cloud Robotics Core: Kubernetes, Federation, App Management

Wyverald/envoy 0

Cloud-native high-performance edge/middle/service proxy

IssuesEvent

issue commentbazelbuild/bazel

No way for bzlmod to depend on non-modularised external dependencies

Ah, true -- we were thinking about introducing an http.archive tag too.

shs96c

comment created time in 2 days

issue commentbazelbuild/bazel

Manifest-based runfiles lookup is non-hermetic

Yeah the problem is really that we can't find the actual link to the doc, just the /pub link. But I'll ask Lukács anyhow. Thanks!

fmeum

comment created time in 5 days

issue commentbazelbuild/bazel

Manifest-based runfiles lookup is non-hermetic

@laszlocsomor do you by any chance know what happened to your doc? :)

fmeum

comment created time in 5 days

issue closedbazelbuild/bazel

No way for bzlmod to depend on non-modularised external dependencies

Description of the problem / feature request:

Quite often rulesets depend on resources that are downloaded using http_file. As an example, rules_jvm_external depends on downloading both coursier and jq as tools that it uses. In a WORKSPACE file, this is easy: a call to http_file and the job is done. bazel_dep doesn't allow this behaviour, which means that it's impossible to use these kinds of dependencies when using a purely modularised build.

Further, some of these dependencies are only used using development, so the equivalent of bazel_dep's dev_dependency flag is needed to prevent unnecessary downloads for users.

Feature requests: what underlying problem are you trying to solve with this feature?

I'd like to be able to download useful tools and artifacts and expose them in a purely modularised build.

What's the output of bazel info release?

release 5.0.0rc3

closed time in 5 days

shs96c

issue commentbazelbuild/bazel

`attr` module not rich enough to describe `bzlmod` attributes

@fmeum

Is it intended behavior that MODULE.bazel permits function definitions?

No, it's a TODO left in the code :P there shouldn't be any def, if, etc. statements in MODULE.bazel, not until we consciously allow them.

@shs96c

Can you suggest a way of expressing this kind of constraint in a way that "deals with it", but which is also something users might be comfortable using? Users do expect to be able to specify exclusions on a per-artifact basis, and I can't see a particularly neat way of doing this.

We talked about this offline today, but for posterity: what I suggest is that we exploit the flexibility of the tag syntax. Say you have something like the following in today's rules_jvm_external:

maven_install(
    name = "maven",
    artifacts = [
        maven.artifact(
            "foo:bar:1.0",
            maven.exclude(
                foo = "bar",
                bar = "foo",
            ),
        ),
        "blah:bleh:2.0",
        "blih:bluh:3.0",
    ],
)

It's all in one call because we're generating just one repo. But because tags are aggregated in Bzlmod, we could just split this into multiple tags, effectively "flattening" the attribute structure:

maven.install(coords = [
    "blah:bleh:2.0",
    "blih:bluh:3.0",
])
maven.artifact(coord = "foo:bar:1.0", exclude = { "foo" : "bar", "bar" : "foo" })

This isn't always easy (expecially if you have very complex inputs with 3+ layers), but it probably will deal with most sensible cases.


Like others have alluded to, an attr.json type is definitely not making it into the BUILD language. It could work as a Bzlmod-only attribute type but that is obviously not ideal either: discrepancy between use sites of attr isn't great, and considering we (Bzlmod) have similar needs as the BUILD language regarding attributes such as serializing and tracking the labels inside, we'd have similar reservations about introducing it anyway.

I'd like to encourage people to try the "flattening" idea above and see whether it works for your use case. If it's still really awkward, we can deliberate further.

shs96c

comment created time in 5 days

issue commentbazelbuild/bazel

Workspaces created by `bzlmod` extensions cannot reference main workspace

The root problem is that labels carry capabilities, but they don't survive the "text" layer that repo rules have to go through to create BUILD files.

In foo/MODULE.bazel:

bazel_dep(name="bar", version="1.0")
ext = use_extension("@bar//:extensions.bzl", "ext")
ext.tag(label = "//my:label")

This allows @bar's extension ext to read the label @foo//my:label, even though @bar normally has no visibility into @foo. And then ext can pass this label on to whatever repo rule it's calling, which means that the repo rule can now read @foo//my:label.

repo_rule = repository_rule(implementation=..., attrs={"label":attr.label()})
def _ext_impl(mctx):
  repo_rule(name="my_repo",label=mctx.modules[0].tag[0].label)

The problem arises when we'd like to read @foo//my:label at BUILD time -- that is, have some BUILD file in @my_repo that can refer to @foo//my:label. The only way to generate a BUILD file is through generating text in repo_rule's impl function. Despite repo_rule's impl function having access to a Label object, it cannot somehow pass this on to the BUILD file without serializing it, at which point it loses the access capability and must go through repo mapping again.

We need to think about how to solve this problem.

shs96c

comment created time in 5 days

delete branch Wyverald/bazel

delete branch : fix-build

delete time in 5 days

push eventbazelbuild/bazel

Xùdōng Yáng

commit sha 38117d491cbc4a5686e0bdb1e58f8946d96aed58

Fix build after rc4 cherrypicks (#14581)

view details

push time in 5 days

pull request commentbazelbuild/bazel

Fix build after rc4 cherrypicks

cc @meteorcloudy

Wyverald

comment created time in 5 days

issue commentbazelbuild/bazel

No way for bzlmod to depend on non-modularised external dependencies

I think it's probably cleaner to go with @fmeum's example -- this way, you don't have to copy http_file's attributes into a tag class. You don't need to write what you want to download in the MODULE.bazel file anyway -- just write them in the extension impl function.

shs96c

comment created time in 5 days

create barnchWyverald/bazel

branch : fix-build

created branch time in 5 days

PR opened bazelbuild/bazel

Fix build after rc4 cherrypicks
+2 -2

0 comment

1 changed file

pr created time in 5 days

issue closedbazelbuild/bazel

Json Genie: 20220113_214645.json

Shared with JSON Genie (Android): http://play.google.com/store/apps/details?id=com.tuyware.jsongenie

closed time in 6 days

Shan2017

issue closedbazelbuild/bazel

Json Genie: 20220113_214434

Shared with JSON Genie (Android): http://play.google.com/store/apps/details?id=com.tuyware.jsongenie

closed time in 6 days

Shan2017

issue commentbazelbuild/bazel

`attr` module not rich enough to describe `bzlmod` attributes

Unfortunately the last of these is actually the least realistic, since MODULE.bazel evaluation happens before the dependencies are fetched (or even which version we need is determined at all). This is the real reason why load statements aren't permitted in MODULE.bazel files, because it's simply impossible to support. (Similarly, tags aren't type-checked until right before module extension evaluation starts; before that, tags are just stored verbatim.)

I think a fourth possibility might be just to "deal with it" and use an API that doesn't include very complex attribute structures. attr is intentionally limited in its expressiveness mostly for the consideration of BUILD files (see linked code comment below). The same arguments don't apply as much to MODULE.bazel files, but still, food for thought.

https://github.com/bazelbuild/bazel/blob/3d78dc7e3a927612c23a6d1542bc38aad5a9703e/src/main/java/com/google/devtools/build/lib/packages/Type.java#L58-L80

shs96c

comment created time in 6 days

push eventbazelbuild/bazel

wyv

commit sha 48a0fc51ccf6a3a263b9f8d96921d84d4243e0e6

Automated rollback of commit 7d09b4a15985052670244c277e4357557b4d0039. *** Reason for rollback *** Now that unknown commit has been submitted, we can roll this forward with a small fix. *** Original change description *** Automated rollback of commit 13112c027c0064cf0a29256e80560cb6630af94d. *** Reason for rollback *** Causes [failures](https://buildkite.com/bazel/google-bazel-presubmit/builds/52620) in Presubmit of unknown commit, itself a Rollback of https://github.com/bazelbuild/bazel/commit/78d01316b22667e9d1758472c91dfee35cc189bd *** Original change description *** Bzlmod: When evaluating extensions in the main repo, do not load WORKSPACE (https://github.com/bazelbuild/bazel/issues/13316) See new comment in BzlLoadFunction.java for details. https://github.com/bazelbuild/bazel-central-registry/pull/47#issuecomment-998883652 also has a bit more context. *** PiperOrigin-RevId: 417820112

view details

wyv

commit sha a233aaa649572b7173ea27aceed31cb705d7ba9b

Bzlmod: Starlarkify default attr values for TypeCheckedTags (https://github.com/bazelbuild/bazel/issues/13316) Attribute values are stored normally as "native" values (ie. Java types), and we Starlarkify them before exposing them to Starlark. We were, however, not doing it for attribute default values, which means that the Java `null` was not being converted to Starlark `None`, and the Java `ImmutableMap` was not being converted to Starlark `Dict`, etc. Fixes https://github.com/bazelbuild/bazel/issues/14528. PiperOrigin-RevId: 421046160

view details

push time in 6 days

issue commentbazelbuild/bazel

Not all attributes are present in module tags with sensible default values

re: cherrypicking, after much deliberation with Yun, we've decided to cherrypick the bzlmod-related fixes (~3 commits) into 5.0, given that these are for an explicitly experimental feature and won't affect any other component of Bazel, and are hence very low-risk, despite them not strictly being regressions.

This does mean that any breakages resulting from those fixes won't be fixed before 5.0 actually ships. If this does happen (and unrelated bugs are likely to be discovered anyhow), we'll try to fix them in a 5.1 point release.

shs96c

comment created time in 6 days

issue commentbazelbuild/bazel

Not all attributes are present in module tags with sensible default values

You can use dict/list attributes on tag_classes, but you can't not specify those attributes (without the fix, that is).

shs96c

comment created time in 6 days

create barnchbazelbuild/bazel

branch : release-5.0.0rc4

created branch time in 6 days

issue commentbazelbuild/bazel

bazel 5.0.0rc3 crashes with local and remote actions being done

@philsc Thank you! Given how elusive this issue is and its relatively low prevalence, I talked to a few people and decided to go ahead and release an RC4 without resolving this issue. If we can get this debugged and resolved soon-ish (say within a week from now), then we can cherrypick the fix, otherwise we'll just ship 5.0 and aim for a 5.0.1 point release to eventually fix this.

philsc

comment created time in 6 days

issue commentbazelbuild/bazel

bzlmod modules cannot depend on extensions declared in the same module

Hey Simon, I believe this was fixed in https://github.com/bazelbuild/bazel/commit/13112c027c0064cf0a29256e80560cb6630af94d. Could you try with Bazel HEAD?

shs96c

comment created time in 6 days

issue commentbazelbuild/bazel

No way for bzlmod to depend on non-modularised external dependencies

What's wrong with using an extension?

shs96c

comment created time in 6 days

push eventbazelbuild/bazel

ajurkowski

commit sha 43bcf80a3dfdc5ac89c1e4d615d6f29a495855fb

Disable implicitly collecting baseline coverage for toolchain targets. Toolchain targets can be evaluated with a [custom execution platform](https://github.com/bazelbuild/bazel/blob/b0a01af6fd0c5f3dce634cb827c75e818835e402/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetKey.java#L168) without affecting the configuration. In particular, we can have 2 `ToolchainDependencyConfiguredTargetKey` with the same label and configuration, but different `executionPlatformLabel`. When coverage is enabled, [every target](https://github.com/bazelbuild/bazel/blob/b0a01af6fd0c5f3dce634cb827c75e818835e402/src/main/java/com/google/devtools/build/lib/analysis/RuleConfiguredTargetBuilder.java#L160-L166) will have a [`baseline_coverage.dat` file generated with `BaselineCoverageAction`](https://github.com/bazelbuild/bazel/blob/33f7648fbaa875f73416be47f0b3c10ed93f30d6/src/main/java/com/google/devtools/build/lib/analysis/test/BaselineCoverageAction.java#L108-L114). This action will use the execution platform from the rule, meaning that in case of the same 2 toolchains, differing by execution platform only, we will create a coverage action with the same output (path based on configuration), but [different key](https://github.com/bazelbuild/bazel/blob/d657619c9c162c6e8c8f56b66e8bef4285d81944/src/main/java/com/google/devtools/build/lib/actions/ActionKeyCacher.java#L65-L70). This fails in analysis since that constitutes a conflicting shared action. Disable coverage for toolchain targets to prevent actions from being created for those. Fixes #14521. PiperOrigin-RevId: 421317916

view details

push time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentbazelbuild/bazel

Changes http_archive's netrc attr to a Label.

The "string-but-treat-as-label-sometimes" setup doesn't work very well even without Bzlmod -- if a user passes in "//some:label" it should refer to "@//some:label", but if we just treat it as a label it would point to "@bazel_tools//some:label". Not to mention that the user could pass in a relative label (":label"), which doesn't work for a Label() call.

IMO the netrc_label attribute idea is the only feasible one.

jiawen

comment created time in 7 days

issue commentbazelbuild/bazel

bazel 5.0.0rc3 crashes with local and remote actions being done

@philsc gentle ping. This is one of the last release blockers of 5.0 and I'd like to push out a final RC as soon as possible.

philsc

comment created time in 7 days

issue closedbazelbuild/bazel

all

closed time in 7 days

Shan2017
more