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