python bindings: Add tools, drop hard abseil dependency

[nicholasjng]

Follow-up of #2016.

tl,dr: It would be to add the analysis tools of benchmark results to the google-benchmark Python package instead of keeping them in a separate directory. Benefits of this are easier installation for the user, being able to use them outside of CMake, and better organization of Python sources for GBM.

Bonus: The absl-py dependency should be dropped. Since that is used for flag parsing, bindings for the flag values should be added as well as an argparse solution.

[LebedevRI]

I personally think dropping abseil dep would be good,
but i'm not quite sure why/how specifically it would be better
if the compare.py script would be installed from bindinds.

It has no particular relationship with bindings,
it does not have a globally-unique descriptive name,
it isn't meant to be in $PATH, but meant to be invoked with it's full path,
it can't be used as a library in a script.

find /usr/share/ -iname \*.py shows quite a bit of existing scripts,
so i think #2016 would not be inventing something new.

[nicholasjng]

I agree - since abseil is not used in the C++ component of the library, it might also make sense to do without it in the Python part.

In my mind, tool usage would then look like this:

# Python virtual environment / Docker container / ...
python -m pip install google-benchmark
# or: uv pip install google-benchmark

python -m google_benchmark.compare res1.json res2.json [--options]
# similarly for the other tools.

by defining some entry points in the pyproject.toml. This prevents cluttering the user env with the tools (i.e., they are only on $PATH if the venv is currently activated), and follows what I would call standard Python packaging practices. Plus, if the user does not need them, making their dependencies optional (with a dependency group, for example) prevents dependency bloat.

What do you think?

[LebedevRI]

Note that the version of the library, and of the tools, basically must be in sync.
Newer tools may support inputs from older library versions, but not the other way around.

Personally, the way i have been using the tools,
is by literally running them from the source tree of the repo.
This isn't an answer, i don't have one.