This was pointed out in a thread on bazel-discuss@googlegroups.com

* feat: add optional pkg alias generation to pip_repository

* feat: support using aliases in gazelle

* doc: migrate gazelle example to use user friendly aliases

* feat: gazelle supports bzlmod

* chore: update gazelle plugin deps

* chore: bazel run //:gazelle

* fix: remove deps that are imported as bazel deps

See: bazel-contrib/bazel-gazelle#1403

* ci: add build_file_generation to show that we support bzlmod

The existing template is very verbose with many of the lines not being
applicable to any given PR. This also makes the PR description poorly
suitable for a commit description.

By having a cleaner PR description that is commit message friendly,
whoever merges the PR can more easily create a meaningful commit
message. It also allows other maintainer's to clean up the description
prior to it being merged.

Update requirements.bzl

…ster_toolchains (#1114)

This is so that the transitive dependencies of defs.bzl can be easily
found and validated; some Google internal tooling does this validation.

The old comment indicated bzl_library wasn't used to avoid a dependency
on skylib, however, we've since added a dependency on skylib.

Work towards #1069

## PR Checklist

Please check if your PR fulfills the following requirements:

- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been added / updated (for bug fixes / features)


## PR Type

What kind of change does this PR introduce?

<!-- Please check the one that applies to this PR using "x". -->

- [X] Bugfix
- [ ] Feature (please, look at the "Scope of the project" section in the
README.md file)
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:


## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or
link to a relevant issue. -->

With `common --experimental_enable_bzlmod` option defs.bzl is generated
as
```
load("@rules_python~override//python/config_settings:transition.bzl", _py_binary = "py_binary", _py_test = "py_test")
load("@rules_python~override//python:pip.bzl", _compile_pip_requirements = "compile_pip_requirements")
```
and these lines cause a problem at
```
load("@python3_9//:defs.bzl", "interpreter")
```
as
```

ERROR: .../BUILD:25:11: error loading package 'src': at .../external/rules_python~override~python~python3_9/defs.bzl:4:6: Unable to find package for @[unknown repo 'rules_python~override' requested from @rules_python~override~python~python3_9]//python:pip.bzl: The repository '@[unknown repo 'rules_python~override' requested from @rules_python~override~python~python3_9]' could not be resolved: No repository visible as '@rules_python~override' from repository '@rules_python~override~python~python3_9'. and referenced by '...'
```


Issue Number: N/A


## What is the new behavior?

Generated load statements
```
load("@@rules_python~override//python/config_settings:transition.bzl", _py_binary = "py_binary", _py_test = "py_test")
load("@@rules_python~override//python:pip.bzl", _compile_pip_requirements = "compile_pip_requirements")
```

## Does this PR introduce a breaking change?

- [ ] Yes
- [X] No


<!-- If this PR contains a breaking change, please describe the impact
and migration path for existing applications below. -->


## Other information

…1113)

Expands make variables in to `abi` and `python_tag` attributes

---------

Co-authored-by: Richard Levasseur <richardlev@gmail.com>

This is mostly so Google internal tooling can find the complete deps,
but also as a best practice for consumption by other rules and tools.

The license comments aren't necessary anymore.

This is to prevent accidentally leaking targets that shouldn't be
accessible. The `:python_toolchain` target is public because it's an
implicit dependency of `py_proto_library`.

The rest of the project uses BUILD.bazel

This is basically a performance optimization. Bazel can only see that a
bzl file changed, not the particular contents. This means that any
downstream bzl file loading it is invalidated, even if it doesn't load
any of the affected code. As an example, if a package only loads
`py_library.bzl`, then changing `py_test.bzl` doesn't need to invalidate
all libraries.

* Also removes some more extraneous license comments

Work towards #1069

Silent r's are tricky.

This provides a public entry point for loading the underlying
`PyCcLinkParamsProvider` provider that is built into Bazel. This
provider isn't yet usable from Bazel, but adding a loadable way for it
to migrate off the built-in rules is the first step.

Work towards #1069

The extraneous newlines were bothering me.