I'm seeing if I can upstream thundergolfer/bazel-mypy-integration#43, but we can also point at my fork for the time being.
This should resolve conflicts with mypy treating imports as non-hermetic, creating inconsistent behavior if packages are/aren't installed locally.
- Shift some things around to adjust to being in bazel.
- Add separate build/serve/publish scripts for use by bazel (not set up for direct execution, but bazel requires +x).
- Fix some tests I noticed not running unittest.main as a result of the switch.
- Move md files into filegroups for build reuse.
- Disable automatic site publishing (now `bazel run //website/jekyll:publish`)
Site publishing seems like it'd be too much trouble to keep automated... The C++ toolchain essentially needs to be set up due to the repo config, along with syncing the LLVM submodules, etc. That seems a bit annoying to do on each run of the publish-docs action, and not something I really want to maintain. If we get a CI, we can focus on it more there, but this feels like it'd just be a one-off to maintain as a github workflow.
Now that we've centralized on a monorepo, tidy up some lingering
references.
For the `pr_comments.py` script, I've left the flag in place to select
a repository as it seems useful functionality to have available even if
we don't expect to need it in the near term. That said, I can pull it
out if folks prefer.
I haven't updated any of the *proposals* because it seems better to
leave those as-is from when they were written. The references seem
unlikely to be confusing to me. Happy for suggestions if needed there
though.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Jon Meow
Chandler CarruthandJon Meow