With the Bazel build transitioning to BzlMod, all vendored Bazel Python targets must be removed. These targets are not available in the BCR and need be managed via a pip `requirements.bazel.txt` file. gRPC already uses this approach, so it is going to be extended to include those target. (e.g. see [test utils](https://github.com/grpc/grpc/blob/e06ad82c3fdde9ec6598d314998d88e848f4c577/test/cpp/naming/utils/BUILD#L27-L45) to understand how those targets are used)
Additionally, the generation of the `requirements.bazel.lock` file has been improved. Because this file is a lock file, including all transitive dependencies, manual maintenance is not managable. Its new source file, `requirements.bazel.txt` is created to list only the direct dependencies used by gRPC, along with instructions for generating the full lock file. This source file omits specific version requirements to use the latest available versions, but version constraints can be added as needed.
Closes#38692
PiperOrigin-RevId: 724427578
- Switched from yapf to black
- Reconfigure isort for black
- Resolve black/pylint idiosyncrasies
Note: I used `--experimental-string-processing` because black was
producing "implicit string concatenation", similar to what described
here: https://github.com/psf/black/issues/1837. While currently this
feature is experimental, it will be enabled by default:
https://github.com/psf/black/issues/2188. After running black with the
new string processing so that the generated code merges these `"hello" "
world"` strings concatenations, then I removed
`--experimental-string-processing` for stability, and regenerated the
code again.
To the reviewer: don't even try to open "Files Changed" tab 😄 It's
better to review commit-by-commit, and ignore `run black and isort`.
* Run 2to3 on tools directory
* Delete github_stats_tracking
* Re-run 2to3
* Remove unused script
* Remove unused script
* Remove unused line count utility
* Yapf. Isort
* Remove accidentally included file
* Migrate tools/distrib directory to python 3
* Remove unnecessary shebang
* Restore line_count directory
* Immediately convert subprocess.check_output output to string
* Take care of Python 2 shebangs
* Invoke scripts using a Python 3 interpreter
* Yapf. Isort
* Try installing Python 3 first
* See if we have any Python 3 versions installed
* Add Python 3.7 to Windows path
* Try adding a symlink
* Try to symlink differently
* Install six for Python 3
* Run run_interop_tests with python 3
* Try installing six in python3.7 explicitly
* Revert "Try installing six in python3.7 explicitly"
This reverts commit 2cf60d72f388a95d642b2c99a775d88a6248f788.
* And debug some more
* Fix issue with jobset.py
* Add debug for CI failure
* Revert microbenchmark changes
* Add isort_code.sh to sanity tests
* Run tools/distrib/isort_code.sh
* Fine tune the import order for relative imports
* Make pylint and project generation happy
* Fix a few corner cases
* Use --check instead of --diff
* The import order impacts test result somehow
* Make isort print diff and check output at the same time
* Let tools/run_tests/python_utils be firstparty library
* Run isort against latest HEAD
Fix a RexAnalyzer error during the import, and update in github as well.
Parentheses around a single item in Python has no effect: (foo) is exactly equivalent to foo. In many cases this is harmless, but it can suggest a subtle bug when used in string formatting. A '%'-formatted string with a single format specifier can be formatted using a single value or a one element tuple: 'hello %s' % name or 'hello %s' % (name,). Consequently, a line like error_msg = 'Cannot process %s' % (data) may leave code reviewers and future readers unsure if there is a subtle bug if data is a tuple.
Since the args.repo_owner here is a single string, drop the parentheses is better.
* Merge unnecessary arguments
* Remove the build command (CI should make sure it works, not this script)
* Speed up the GitHub operations with proper flags
* Adding Sphinx to setup requirement
Esun Kim