The upcoming Bazel version defaults to having bzlmod enabled, which means workspace
builds will need to explicitly disable it to continue to be workspace-based.

bazelbuild/bazel#18958

A recent commit changed the order to satisfy the internal ordering, but
ended up breaking the external ordering.

PiperOrigin-RevId: 572474447

The last couple releases didn't have the changelog updated to reflect what
was actually released.

PiperOrigin-RevId: 588396254

This removes a hack to make the dev-only register_toolchains() call
not break the production configuration. This hack is no longer necessary
as of rules_python 0.23.0 and higher. Version 0.27.0 is chosen because
the latest release has some code for building Sphinx documentation
I'd like to experiment with re-using.

Coincidentally, this should also fix an an issue with the Bazel@HEAD
downstream CI pipeline running tests for Mac/Windows that should be
skipped, but fail due to very early MODULE-phase errors. With this
change, it's able to get past that failure and run enough that the
Bazel@HEAD downstream CI should be happy. Note those tests aren't
gauranteed to continue to work on those platforms, they just happen to.

Fixes #76

PiperOrigin-RevId: 589135805

This allows customizing what attributes are considered a target under test,
i.e. that they have aspects, config settings, etc applied. This allows having
multiple targets be tested, which is useful for comparing targets in different
configurations, multiple targets with a custom configuration, or some combination
of that.

When this is used, the implementation function is passed a struct of the
targets under test, keyed by their attribute name, instead of the singular
target under test.

Fixes #67

PiperOrigin-RevId: 589888837

By convention, rule-like macros and rules should be called with keyword args.
Enforce this by using `*` notation in the `analysis_test` signature.

BREAKING CHANGE:
  * If you were passing any positional args, you must update the calls
    to use keyword args.

PiperOrigin-RevId: 590253370

Currently, If you are testing a custom provider, the API requires you to write:
    env.expect.that_target(targets.foo).provider(FooInfo, factory=FooFactory)...
    env.expect.that_target(targets.foo).provider(BarInfo, factory=BarFactory)...

This can get very tedious, and more importantly, is not very safe, since you can write:
    env.expect.that_target(targets.foo).provider(FooInfo, factory=FooFactory)...
    env.expect.that_target(targets.foo).provider(BarInfo, factory=FooFactory)...

Additionally, custom types are always rendered as "<provider>".

To solve this, we add the ability to directly specify a list of factories for custom types in your test.

analysis_test(
    ...,
    provider_factories = [struct(type = FooInfo, name = "FooInfo", factory = FooFactory)]
)

PiperOrigin-RevId: 607174706

PiperOrigin-RevId: 607232096

PiperOrigin-RevId: 607261014

PiperOrigin-RevId: 608172011

…n attrs, and attrs in a mandatory attribute for the new function on a struct.

Also add expect.that_value to allow you to work with arbitrary types

PiperOrigin-RevId: 608252913

…efined

def factory(value, meta)

but would fail if you wrote the signature as

def factory(value, *, meta)

PiperOrigin-RevId: 608504071