Hi David,

On 09/07/25 03:33, David Faust wrote:
diff --git a/contrib/bpf-vmtest-tool/.gitignore 
b/contrib/bpf-vmtest-tool/.gitignore
new file mode 100644
index 00000000000..723dfe1d0f4
--- /dev/null
+++ b/contrib/bpf-vmtest-tool/.gitignore
@@ -0,0 +1,23 @@
+.gitignore_local
+.python-version
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# Unit test / coverage reports
+.pytest_cache/
+
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Ruff stuff:
+.ruff_cache/

Will the files be e.g. byte-compiled in typical use?  At a glance I think
most (all?) of these will never be created in ordinary usage.  If that's
the case we can probably not include this local .gitignore at all.


In normal use, only __pycache__ would be generated, but I checked, and the project's root .gitignore already covers it at line 17. So we can drop this .gitignore


+DEVELOPMENT
+===========
+
+Development dependencies are specified in `pyproject.toml`, which can be used
+with any suitable Python virtual environment manager.
+
+To run the test suite:
+
+    python3 -m pytest

Can the tests be run without a pyproject.toml, or is it required?
(I mean the tests of bpf-vmtest-tool itself)
The current tests can be run with "python3 -m pytest --import-mode=importlib tests" without pyproject.toml. But some pytest options can only be specified in pyproject.toml file and don't have command-line alternatives.
As far as I understand it is typically for packages. But in this case
it seems, now that we don't have external deps, to come down to a local
development utility thing along the lines of .clang-format or so, which
we aren't checking in.
Yes, pyproject.toml is used for packaging python projects, but it's also used by tools like pytest and ruff under their [tool.*] tables (see: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/ ) While it's not needed to run the script itself, most development tools depend on it, so I think it makes sense to include it in the source to help set up consistent development environments.

+# https://git.sr.ht/~brianwitte/gcc-bpf-example/tree/master/item/Makefile

Is this comment attached to anything in particular?

I guess you followed here the same structure outlined in Brian Witte's Makefile,
right?  It would be good give a bit of context to the link, otherwise it just
seems out of place.
Thanks. I'll add clarification that the current implementation uses Brian's Makefile as a reference.

Best regards,
Piyush

Reply via email to