chore(pip_parse, gazelle): generate/use hub repo aliases by default (#1525)

This makes `pip_parse.incompatible_generate_aliases = True` the default.
This only affects
workspace builds; it is already the default for bzlmod.

Summary:
- Enable the generation of aliases in `pip_repository`.
- Flip usage of aliases in `gazelle`.
- Remove usage of the old flags from the example code.
- Update the `gazelle` manifest generator to leave the
  `gazelle_python.yaml` manifest unchanged for people who have
  `use_pip_repository_aliases = True` in their `BUILD.bazel` files.
  Once they remove the flag, the `gazelle_python.yaml` will be updated.
- Update `multi_pip_parse` to handle sub-hub repositories where
  the `all_requirements` returns aliased targets.

Fixes #1498

Author: aignas

CHANGELOG.md

@@ -25,12 +25,24 @@ A brief description of the categories of changes:
   as all of the publicly available symbols (etc. `package_annotation`) are
   re-exported via `//python:pip_bzl` `bzl_library`.
 
-* Gazelle Python extension no longer has runtime dependencies. Using
+* (gazelle) Gazelle Python extension no longer has runtime dependencies. Using
   `GAZELLE_PYTHON_RUNTIME_DEPS` from `@rules_python_gazelle_plugin//:def.bzl` is
   no longer necessary.
 
-* The installation of `pip_parse` repository rule toolchain dependencies is now
-  done as part of `py_repositories` call.
+* (pip_parse) The installation of `pip_parse` repository rule toolchain
+  dependencies is now done as part of `py_repositories` call.
+
+* (pip_parse) The flag `incompatible_generate_aliases` has been flipped to
+  `True` by default on `non-bzlmod` setups allowing users to use the same label
+  strings during the transition period. For example, instead of
+  `@pypi_foo//:pkg`, you can now use `@pypi//foo` or `@pypi//foo:pkg`. Other
+  labels that are present in the `foo` package are `dist_info`, `whl` and
+  `data`. Note, that the `@pypi_foo//:pkg` labels are still present for
+  backwards compatibility.
+
+* (gazelle) The flag `use_pip_repository_aliases` is now set to `True` by
+  default, which will cause `gazelle` to change third-party dependency labels
+  from `@pip_foo//:pkg` to `@pip//foo` by default.
 
 Breaking changes:
 

examples/build_file_generation/BUILD.bazel

@@ -43,9 +43,6 @@ gazelle_python_manifest(
     # NOTE: We can pass a list just like in `bzlmod_build_file_generation` example
     # but we keep a single target here for regression testing.
     requirements = "//:requirements_lock.txt",
-    # NOTE: we can use this flag in order to make our setup compatible with
-    # bzlmod.
-    use_pip_repository_aliases = True,
 )
 
 # Our gazelle target points to the python gazelle binary.

examples/build_file_generation/WORKSPACE

@@ -94,8 +94,6 @@ load("@rules_python//python:pip.bzl", "pip_parse")
 # You can instead check this `requirements.bzl` file into your repo.
 pip_parse(
     name = "pip",
-    # Generate user friendly alias labels for each dependency that we have.
-    incompatible_generate_aliases = True,
     # (Optional) You can provide a python_interpreter (path) or a python_interpreter_target (a Bazel target, that
     # acts as an executable). The latter can be anything that could be used as Python interpreter. E.g.:
     # 1. Python interpreter that you compile in the build file.

examples/build_file_generation/gazelle_python.yaml

@@ -114,5 +114,4 @@ manifest:
     zipp.py310compat: zipp
   pip_repository:
     name: pip
-    use_pip_repository_aliases: true
-integrity: 030d6d99b56c32d6577e616b617260d0a93588af791269162e43391a5a4fa576
+integrity: a88d99bf5ea018bdb052ccda8ea5c98b6bae81312a338f909532285b76026fe1