Merge remote-tracking branch 'origin/main' into HEAD

Author: philsc

CHANGELOG.md

@@ -52,6 +52,30 @@ Unreleased changes template.
 
 {#v0-0-0-changed}
 ### Changed
+* Nothing changed.
+
+{#v0-0-0-fixed}
+### Fixed
+* Nothing fixed.
+
+{#v0-0-0-added}
+### Added
+* Nothing added.
+
+{#v0-0-0-removed}
+### Removed
+* Nothing removed.
+
+{#v1-2-0}
+## Unreleased
+
+[1.2.0]: https://github.com/bazelbuild/rules_python/releases/tag/1.2.0
+
+{#v1-2-0-changed}
+### Changed
+* (rules) `py_proto_library` is deprecated in favour of the
+  implementation in https://github.com/protocolbuffers/protobuf. It will be
+  removed in the future release.
 * (pypi) {obj}`pip.override` will now be ignored instead of raising an error,
   fixes [#2550](https://github.com/bazelbuild/rules_python/issues/2550).
 * (rules) deprecation warnings for deprecated symbols have been turned off by
@@ -60,7 +84,7 @@ Unreleased changes template.
 * (pypi) Downgraded versions of packages: `pip` from `24.3.2` to `24.0.0` and
   `packaging` from `24.2` to `24.0`.
 
-{#v0-0-0-fixed}
+{#v1-2-0-fixed}
 ### Fixed
 * (rules) `python_zip_file` output with `--bootstrap_impl=script` works again
   ([#2596](https://github.com/bazelbuild/rules_python/issues/2596)).
@@ -82,11 +106,11 @@ Unreleased changes template.
   build time (they will be created at runtime instead).
   (Fixes [#2489](https://github.com/bazelbuild/rules_python/issues/2489))
 
-{#v0-0-0-added}
+{#v1-2-0-added}
 ### Added
 * Nothing added.
 
-{#v0-0-0-removed}
+{#v1-2-0-removed}
 ### Removed
 * Nothing removed.
 

CONTRIBUTING.md

@@ -3,6 +3,21 @@
 We'd love to accept your patches and contributions to this project. There are
 just a few small guidelines you need to follow.
 
+## Contributor License Agreement
+
+First, the most important step: signing the Contributor License Agreement. We
+cannot look at any of your code unless one is signed.
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement. You (or your employer) retain the copyright to your contribution,
+this simply gives us permission to use and redistribute your contributions as
+part of the project. Head over to <https://cla.developers.google.com/> to see
+your current agreements on file or to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it
+again.
+
 ## Getting started
 
 Before we can work on the code, we need to get a copy of it and setup some
@@ -65,15 +80,6 @@ and setup. Subsequent runs will be faster, but there are many tests, and some of
 them are slow. If you're working on a particular area of code, you can run just
 the tests in those directories instead, which can speed up your edit-run cycle.
 
-## Updating tool dependencies
-
-It's suggested to routinely update the tool versions within our repo - some of the
-tools are using requirement files compiled by `uv` and others use other means. In order
-to have everything self-documented, we have a special target -
-`//private:requirements.update`, which uses `rules_multirun` to run in sequence all
-of the requirement updating scripts in one go. This can be done once per release as
-we prepare for releases.
-
 ## Formatting
 
 Starlark files should be formatted by
@@ -99,18 +105,6 @@ $ buildifier --lint=fix --warnings=native-py -warnings=all WORKSPACE
 
 Replace the argument "WORKSPACE" with the file that you are linting.
 
-## Contributor License Agreement
-
-Contributions to this project must be accompanied by a Contributor License
-Agreement. You (or your employer) retain the copyright to your contribution,
-this simply gives us permission to use and redistribute your contributions as
-part of the project. Head over to <https://cla.developers.google.com/> to see
-your current agreements on file or to sign a new one.
-
-You generally only need to submit a CLA once, so if you've already submitted one
-(even if it was for a different project), you probably don't need to do it
-again.
-
 ## Code reviews
 
 All submissions, including submissions by project members, require review. We
@@ -198,31 +192,6 @@ merged:
   `compile_pip_requirements` update target, which is usually in the same directory.
   e.g. `bazel run //docs:requirements.update`
 
-## Core rules
-
-The bulk of this repo is owned and maintained by the Bazel Python community.
-However, since the core Python rules (`py_binary` and friends) are still
-bundled with Bazel itself, the Bazel team retains ownership of their stubs in
-this repository. This will be the case at least until the Python rules are
-fully migrated to Starlark code.
-
-Practically, this means that a Bazel team member should approve any PR
-concerning the core Python logic. This includes everything under the `python/`
-directory except for `pip.bzl` and `requirements.txt`.
-
-Issues should be triaged as follows:
-
-- Anything concerning the way Bazel implements the core Python rules should be
-  filed under [bazelbuild/bazel](https://github.com/bazelbuild/bazel), using
-  the label `team-Rules-python`.
-
-- If the issue specifically concerns the rules_python stubs, it should be filed
-  here in this repository and use the label `core-rules`.
-
-- Anything else, such as feature requests not related to existing core rules
-  functionality, should also be filed in this repository but without the
-  `core-rules` label.
-
 (breaking-changes)=
 ## Breaking Changes
 

DEVELOPING.md

@@ -17,63 +17,11 @@
    # bazel run //tools/private/update_deps:update_coverage_deps 7.6.1
    ```
 
-## Releasing
-
-Start from a clean checkout at `main`.
-
-Before running through the release it's good to run the build and the tests locally, and make sure CI is passing. You can
-also test-drive the commit in an existing Bazel workspace to sanity check functionality.
-
-### Releasing from HEAD
-
-#### Steps
-1. [Determine the next semantic version number](#determining-semantic-version)
-1. Create a tag and push, e.g. `git tag 0.5.0 upstream/main && git push upstream --tags`
-   NOTE: Pushing the tag will trigger release automation.
-1. Watch the release automation run on https://github.com/bazelbuild/rules_python/actions
-1. Add missing information to the release notes. The automatic release note
-   generation only includes commits associated with issues.
-
-#### Determining Semantic Version
-
-**rules_python** is currently using [Zero-based versioning](https://0ver.org/) and thus backwards-incompatible API
-changes still come under the minor-version digit. So releases with API changes and new features bump the minor, and
-those with only bug fixes and other minor changes bump the patch digit.
-
-To find if there were any features added or incompatible changes made, review
-the commit history. This can be done using github by going to the url:
-`https://github.com/bazelbuild/rules_python/compare/<VERSION>...main`.
-
-### Patch release with cherry picks
-
-If a patch release from head would contain changes that aren't appropriate for
-a patch release, then the patch release needs to be based on the original
-release tag and the patch changes cherry-picked into it.
-
-In this example, release `0.37.0` is being patched to create release `0.37.1`.
-The fix being included is commit `deadbeef`.
-
-1. `git checkout -b release/0.37 0.37.0`
-1. `git push upstream release/0.37`
-1. `git cherry-pick -x deadbeef`
-1. Fix merge conflicts, if any.
-1. `git cherry-pick --continue` (if applicable)
-1. `git push upstream`
-
-If multiple commits need to be applied, repeat the `git cherry-pick` step for
-each.
-
-Once the release branch is in the desired state, use `git tag` to tag it, as
-done with a release from head. Release automation will do the rest.
-
-#### After release creation in Github
-
-1. Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com).
-
-## Secrets
-
-### PyPI user rules-python
-
-Part of the release process uploads packages to PyPI as the user `rules-python`.
-This account is managed by Google; contact [email protected] if
-something needs to be done with the PyPI account.
+## Updating tool dependencies
+
+It's suggested to routinely update the tool versions within our repo - some of the
+tools are using requirement files compiled by `uv` and others use other means. In order
+to have everything self-documented, we have a special target -
+`//private:requirements.update`, which uses `rules_multirun` to run in sequence all
+of the requirement updating scripts in one go. This can be done once per release as
+we prepare for releases.

MODULE.bazel

@@ -10,7 +10,7 @@ bazel_dep(name = "rules_cc", version = "0.0.16")
 bazel_dep(name = "platforms", version = "0.0.4")
 
 # Those are loaded only when using py_proto_library
-bazel_dep(name = "rules_proto", version = "7.0.2")
+# Use py_proto_library directly from protobuf repository
 bazel_dep(name = "protobuf", version = "29.0-rc2", repo_name = "com_google_protobuf")
 
 internal_deps = use_extension("//python/private:internal_deps.bzl", "internal_deps")

RELEASING.md

@@ -0,0 +1,68 @@
+# Releasing
+
+Start from a clean checkout at `main`.
+
+Before running through the release it's good to run the build and the tests locally, and make sure CI is passing. You can
+also test-drive the commit in an existing Bazel workspace to sanity check functionality.
+
+## Releasing from HEAD
+
+### Steps
+1. [Determine the next semantic version number](#determining-semantic-version).
+1. Update CHANGELOG.md: replace the `v0-0-0` and `0.0.0` with `X.Y.0`.
+1. Replace `VERSION_NEXT_*` strings with `X.Y.0`.
+1. Send these changes for review and get them merged.
+1. Create a branch for the new release, named `release/X.Y`
+   ```
+   git branch --no-track release/X.Y upstream/main && git push upstream release/X.Y
+   ```
+1. Create a tag and push:
+   ```
+   git tag X.Y.0 upstream/release/X.Y && git push upstream --tags
+   ```
+   **NOTE:** Pushing the tag will trigger release automation.
+1. Release automation will create a GitHub release and BCR pull request.
+
+### Determining Semantic Version
+
+**rules_python** uses [semantic version](https://semver.org), so releases with
+API changes and new features bump the minor, and those with only bug fixes and
+other minor changes bump the patch digit.
+
+To find if there were any features added or incompatible changes made, review
+[CHANGELOG.md](CHANGELOG.md) and the commit history. This can be done using
+github by going to the url:
+`https://github.com/bazelbuild/rules_python/compare/<VERSION>...main`.
+
+## Patch release with cherry picks
+
+If a patch release from head would contain changes that aren't appropriate for
+a patch release, then the patch release needs to be based on the original
+release tag and the patch changes cherry-picked into it.
+
+In this example, release `0.37.0` is being patched to create release `0.37.1`.
+The fix being included is commit `deadbeef`.
+
+1. `git checkout release/0.37`
+1. `git cherry-pick -x deadbeef`
+1. Fix merge conflicts, if any.
+1. `git cherry-pick --continue` (if applicable)
+1. `git push upstream`
+
+If multiple commits need to be applied, repeat the `git cherry-pick` step for
+each.
+
+Once the release branch is in the desired state, use `git tag` to tag it, as
+done with a release from head. Release automation will do the rest.
+
+### After release creation in Github
+
+1. Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com).
+
+## Secrets
+
+### PyPI user rules-python
+
+Part of the release process uploads packages to PyPI as the user `rules-python`.
+This account is managed by Google; contact [email protected] if
+something needs to be done with the PyPI account.

WORKSPACE

@@ -166,9 +166,3 @@ http_file(
         "https://files.pythonhosted.org/packages/50/67/3e966d99a07d60a21a21d7ec016e9e4c2642a86fea251ec68677daf71d4d/numpy-1.25.2-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl",
     ],
 )
-
-# rules_proto expects //external:python_headers to point at the python headers.
-bind(
-    name = "python_headers",
-    actual = "//python/cc:current_py_cc_headers",
-)

docs/api/rules_python/python/config_settings/index.md

@@ -279,6 +279,6 @@ Values:
 is created.
 :::
 
-:::{versionadded} VERSION_NEXT_PATCH
+:::{versionadded} 1.2.0
 :::
 ::::

docs/environment-variables.md

@@ -44,7 +44,7 @@ being cleaned up by the OS.
 If not set, then a temporary directory will be created and deleted upon program
 exit.
 
-:::{versionadded} VERSION_NEXT_PATCH
+:::{versionadded} 1.2.0
 :::
 ::::
 

examples/bzlmod/MODULE.bazel

@@ -12,9 +12,6 @@ local_path_override(
     path = "../..",
 )
 
-# (py_proto_library specific) We are using rules_proto to define rules_proto targets to be consumed by py_proto_library.
-bazel_dep(name = "rules_proto", version = "6.0.0-rc1")
-
 # (py_proto_library specific) Add the protobuf library for well-known types (e.g. `Any`, `Timestamp`, etc)
 bazel_dep(name = "protobuf", version = "27.0", repo_name = "com_google_protobuf")
 

examples/bzlmod/py_proto_library/BUILD.bazel

@@ -20,11 +20,12 @@ py_test(
 
 # Regression test for https://github.com/bazelbuild/rules_python/issues/2515
 #
-# This test failed before https://github.com/bazelbuild/rules_python/pull/2516
+# This test fails before protobuf 30.0 release
 # when ran with --legacy_external_runfiles=False (default in Bazel 8.0.0).
 native_test(
     name = "external_import_test",
     src = "@foo_external//:py_binary_with_proto",
+    tags = ["manual"],  # TODO: reenable when com_google_protobuf is upgraded
     # Incompatible with Windows: native_test wrapping a py_binary doesn't work
     # on Windows.
     target_compatible_with = select({