Also contains a run of `pre-commit autoupdate`, and a bump of cibuildwheel
to its latest tag for CPython 3.13 support.
But, since we build for 3.10+ with SABI from 3.12 onwards, we don't even
need a dedicated Python 3.13 build job or toolchain - the wheels from 3.12
can be reused.
Simplifies some version-dependent logic around assembling the bazel
build command in setup.py, and fixes a possible unbound local error in
the toolchain patch context manager.
* Supply MacOS deployment target to delocate, use build+uv frontend
This shaves off multiple minutes from the wheel builds alone.
Also revert to trusted publishing for wheel uploads as it is now set up.
* Bump oldest supported Python to 3.10, eliminate setuptools-scm
The version is now a string again, under the same attribute as it was
before. This is a pragmatic decision in order to be able to upload wheels
again, possibly directly from main.
We could in the future also set the Python version to a development version
if we want to avoid accidental uploads of `main`.
* Add a note on supported Python versions in the docs
Also fixes the setuptools failure observed in the latest CI by pinning
to the last version before v73 until the problem is identified and resolved.
* Add a bzlmod Python bindings build
Uses the newly started `@nanobind_bazel` project to build nanobind
extensions. This means that we can drop all in-tree custom build defs
and build files for nanobind and the C++ Python headers.
Additionally, the temporary WORKSPACE overwrite hack naturally goes away
due to the WORKSPACE system being obsolete.
* Bump ruff -> v0.3.1, change ruff settings
The latest minor releases incurred some formatting and configuration
changes, this commit rolls them out.
---------
Co-authored-by: dominic <510002+dmah42@users.noreply.github.com>
Also fix a mypy error in `tools.gbench.util` - the condition behaves the
same as before, but in the new mypy version, the old condition results
in an unreachable code error for the final `return False` statement.
This is most likely a bug in mypy's reachability analysis, but the fix
is easy enough here to circumvent it.
* Run `pre-commit autoupdate`, fix stale pyproject.toml comments
* Set `--enable_bzlmod=false` for the moment
Until the newer nanobind tags are pushed to the BCR, it's best to disable
bzlmod for the bindings, because the Python CI breaks due to Bazel 7
enabling bzlmod by default.
* Remove E203 ignore, add linebreaks to semantically group ruff options
Saves one pre-commit hook, some pyproject.toml configuration,
and provides much better performance with almost identical behavior.
Co-authored-by: dominic <510002+dmah42@users.noreply.github.com>
This behaves the same, and saves a pre-commit step. ruff just needs an
additional package location hint to correctly map first-part packages
(in this case, `google_benchmark`).
This revealed a misformat in the `google_benchmark.__init__`, which is
now fixed.
* Add pre-commit config and GitHub Actions job
Contains the following hooks:
* buildifier - for formatting and linting Bazel files.
* mypy, ruff, isort, black - for Python typechecking, import hygiene,
static analysis, and formatting.
The pylint CI job was changed to be a pre-commit CI job, where pre-commit
is bootstrapped via Python.
Pylint is currently no longer part of the
code checks, but can be re-added if requested. The reason to drop was
that it does not play nicely with pre-commit, and lots of its
functionality and responsibilities are actually covered in ruff.
* Add dev extra to pyproject.toml for development installs
* Clarify that pre-commit contains only Python and Bazel hooks
* Add one-line docstrings to Bazel modules
* Apply buildifier pre-commit fixes to Bazel files
* Apply pre-commit fixes to Python files
* Supply --profile=black to isort to prevent conflicts
* Fix nanobind build file formatting
* Add tooling configs to `pyproject.toml`
In particular, set line length 80 for all Python files.
* Reformat all Python files to line length 80, fix return type annotations
Also ignores the `tools/compare.py` and `tools/gbench/report.py` files
for mypy, since they emit a barrage of errors which we can deal with
later. The errors are mostly related to dynamic classmethod definition.
