I think the following points might benefit GBM's Python distribution. They are all optional, but with varying degrees of usefulness:
[x] Adding a modern build system-compliant (PEP517/518) pyproject.toml.
[ ] Including all C++ source and header files into the wheel, along with the cmake directory; that way, Python people can include GBM as a build-time dependency and e.g. roll their own bindings. nanobind does this, specifically for integrating with scikit-build, for Bazel, it should work the same way.
[ ] Adding a benchmark.parametrize decorator similar to pytest.mark.parameterize or absl.testing.parameterized, so that users don't have to register each benchmark by hand for each set of keyword arguments in the cartesian product.
[ ] Making flag parsing with absl optional by opening up the flag parser as a configurable element of the benchmarking workflow.
[ ] Consolidating all per-benchmark arguments in a single decorator to avoid excessive decorator stacking.
[ ] Adding better IDE support by providing docstrings to the bound Python objects.
I will tackle them as I get the time, especially the registration QoL improvements might be worth it in my opinion.
I think the following points might benefit GBM's Python distribution. They are all optional, but with varying degrees of usefulness:
pyproject.toml.cmakedirectory; that way, Python people can include GBM as a build-time dependency and e.g. roll their own bindings.nanobinddoes this, specifically for integrating withscikit-build, for Bazel, it should work the same way.benchmark.parametrizedecorator similar topytest.mark.parameterizeorabsl.testing.parameterized, so that users don't have toregistereach benchmark by hand for each set of keyword arguments in the cartesian product.absloptional by opening up the flag parser as a configurable element of the benchmarking workflow.I will tackle them as I get the time, especially the registration QoL improvements might be worth it in my opinion.