* Update README.md
If we will remove new_sets, then we should deprecate it instead of sets.
* Update README.md
---------
Co-authored-by: Ivo List <ilist@google.com>
All other test_deps targets implicitly require the root BUILD file
for the `license` target for their default_applicable_licenses;
therefore, users should only depend on the root test_deps target.
* Wrap bzl_library in a macro so that we can force off some
global attribures that are never appropriate for BUILD files.
Removes:
- *_compatible_with
- features
* cdate
* linty
* linty
* more lint
For example, if you try to match `*a*` against `ab`, then we check:
```
left = ""
middle = "a"
right = ""
middle in name[len(left):len(name)-len(right)]:
"a" in "ab"[len(""):len(name)-len("")]:
"a" in "ab"[0:-0]
"a" in "" => False
```
The problem here is that negative numbers in python index from the back, but -0 is not a negative number, so it always results in the empty string.
Previously, I was getting the error
`Expected external/_main~toolchains~toolchain_sdk/usr/bin/clang++ to start with one of ["external/_main~toolchains~toolchain_sdk//", "bazel-out/k8-dbg/bin/external/_main~toolchains~toolchain_sdk/"]`
A common point of confusion I see around `run_binary` is that it's hard coded to only expand `$(location` values which in codebases I work in are otherwise completely eliminated due to it being described as "legacy"
> location: A synonym for either execpath or rootpath, depending on the attribute being expanded. This is legacy pre-Starlark behavior and not recommended unless you really know what it does for a particular rule. See [#2475](https://github.com/bazelbuild/bazel/issues/2475#issuecomment-339318016) for details.
If `execpath` is used instead as the appropriate alternative, the rule does no do any expansion and fails the action. This change adds support for expanding all available patterns whenever they're provided.
Adds a new module `modules` with two helper functions for module
extensions:
* `use_all_repos` makes it easy to return an appropriate
`extension_metadata` from a module extension (if supported) to
indicate that all repositories generated by the extension should be
imported via `use_repo`.
* `as_extension` turns a WORKSPACE macro into a module extension that
uses `use_all_repos` to automate the generation of `use_repo` calls.
Allow `bzl_library` to depend on non-`bzl_library` targets
Notably, `filegroup`. `bzl_library` doesn't actually read anything from the `StarlarkLibraryInfo` provider, and requiring all deps to be other `bzl_library` targets is really painful for anyone loading .bzls from `@bazel_tools` or `@platforms` because those core modules/repos don't want a dependency on Skylib just for access to `bzl_library`.
The medium-term plan will be to move `bzl_library` into `@bazel_tools`; but before then, this can serve as a stop-gap.
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
This improves the error in the case your bzl_library does nothing.
Otherwise you end up with something weirder later:
```
BUILD:35:12: in deps attribute of bzl_library rule LABEL: 'DEP' does not produce any bzl_library deps files (expected .bzl)
```
Ideally we could set `allow_empty = False` on `srcs` but currently it's
valid to just have a bzl_library target that aggregates multiple other
libraries in its deps.
Co-authored-by: Ivo List <ilist@google.com>
Ara Nguyen