The pip dependencies in github_tools are the reason the
MODULE.bazel.lock is platform-dependent. Following complaints about the
platform-dependence, split apart github_tools from the rest of the bazel
repo and make it not track the lockfile: while there's an incremental
safety risk due to not tracking checksums, it's unlikely the tools there
would ever be part of a Carbon release process. If we eventually add
Python tools that need pip to the release, it might be desirable to go
back to re-unify the bazezl repos.
This does make running pr_comments incrementally more inconvenient
because a "bazel run" needs to be run from the github_tools subdir.
As a consequence of separating the dependency, this means tests will not
be continuously run in github_tools. They're now a separate repo, and we
cannot add a dependency without restoring the platform-dependent issue.
I think pr_comments is sufficiently low value and unchanging that it is
not worth building separate CI for it.
Cleans up some legacy references to third_party/llvm-project, since now
github_tools needs to be added to the main bazelignore.
Also requires switching to using `pip_parse` and providing a fully
resolved requirements lock file. This moves the input requirements to
the `requirements.in` file, and processes it with:
```console
$ bazel run //github_tools:requirements.update
```
This will regenerate the `requirements.txt` file that is checked into
the repository. The advice in the documentation is specifically to keep
this file checked into the repository for hermetic builds with stable
Python dependency versions.
This should fix builds on systems where the Python version is 3.12 and
newer and the older version of `rules_python` stops working with errors
due to removal of long-deprecated interfaces.
Jon Ross-Perkins
Chandler Carruth
Jon Meow