[nkltz]

compare.py currently does not have an installation method outside of BAZEL, only a requirements.txt at the folder level; its shebang uses python3 in the env, which assumes a python3 interpreter is set up with dependencies installed.

Add inline script metadata to enable running the script with uv.

In conda (pixi), this enables running:

uv run $CONDA_PREFIX/share/googlebenchmark/tools/compare.py

instead of:

uv run --with-requirements $CONDA_PREFIX/share/googlebenchmark/tools/requirements.txt $CONDA_PREFIX/share/googlebenchmark/tools/compare.py

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[nkltz]

I signed the CLA, does it match on email address?

[LebedevRI]

We'll now have two places where dependencies will be specified, which means they will go out of sync.
Is there some standard practice for this?

[nkltz]

We'll now have two places where dependencies will be specified, which means they will go out of sync. Is there some standard practice for this?

Yes there is, that would be a full-on python package with pyproject.toml and dropping the requirements.txt; I can do that instead if you'd rather.
As a side note they are already repeated between the requirements.txt and the BUILD.bazel

[LebedevRI]

We'll now have two places where dependencies will be specified, which means they will go out of sync. Is there some standard practice for this?

Yes there is, that would be a full-on python package with pyproject.toml and dropping the requirements.txt; I can do that instead if you'd rather. As a side note they are already repeated between the requirements.txt and the BUILD.bazel

I'm not going to speak for everybody, but i think the most important mode of operations for that script is just that,
a script that can simply be run from the repo. Does that still just work with the project approach?
Maybe deps duplication is fine...