build: switch setup.py to pyproject.toml

[igaw]

While at it also add a build workflow and remove the kmod python binding and more build fixes.

Fixes: #11 #15

[Copilot]

Pull request overview

This PR migrates nvmetcli’s Python packaging metadata from a legacy setup.py-driven build to a PEP 517/518 + PEP 621 pyproject.toml configuration.

Changes:

• Removed setup.py to eliminate the legacy setuptools entrypoint.
• Added pyproject.toml with setuptools build backend and project metadata (incl. runtime/test dependencies).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
setup.py	Deleted legacy setuptools packaging script.
pyproject.toml	Introduces PEP 517/518 build config and PEP 621 project metadata, including dependencies and script packaging.

Suppressed comments (2)

pyproject.toml:12

• requires-python = ">=3.6" declares Python 3-only support, but the existing packaging scripts still use python setup.py ... (Debian rules even uses --with python2) and the installed script shebang is /usr/bin/python. This mismatch can lead to building/installing against Python 2 or an arbitrary default python, which will fail given the code uses Python 3-only syntax (e.g. f-strings).

license = { text = "Apache 2.0" }
requires-python = ">=3.6"
maintainers = [

pyproject.toml:23

• The test extra only includes nose2, but make test runs python3 -m nose2 ... --coverage, which requires the coverage module to be installed. Add coverage to the test optional dependencies so a standard pip install .[test] is sufficient to run the test target.

[project.optional-dependencies]
test = [
    "nose2"
]

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (5)

rpm/nvmetcli.spec.tmpl:30

• pip3 install ... . will, by default, resolve/install runtime deps and may also perform an isolated PEP 517 build (downloading build deps). That is undesirable/broken in offline RPM builds and duplicates dependency management already handled by RPM. Add --no-deps --no-build-isolation here. Also note that pip/setuptools will install scripts under the prefix’s bin dir (typically /usr/bin), so the %files entry should match that path (it currently lists /usr/sbin/nvmetcli).

pip3 install --root=%{buildroot} --prefix=usr .

debian/rules:17

• pip3 install will try to resolve/install dependencies and may trigger an isolated PEP 517 build, which can attempt network access (blocked via http_proxy). For Debian packaging, dependencies should come from Build-Depends/Depends instead. Add --no-deps --no-build-isolation to make the build reproducible/offline-friendly.

	pip3 install --root=$(install_dir) --prefix=/usr .

pyproject.toml:19

• Installing the CLI via script-files preserves the script’s original shebang. The nvmetcli script currently starts with #!/usr/bin/python, which can resolve to Python 2 on some systems, conflicting with requires-python = ">=3.6". Consider switching to a console-script entry point (preferred) or updating the nvmetcli script shebang to python3 to ensure the installed command always uses Python 3.

[tool.setuptools]
packages = ["nvmet"]
script-files = ["nvmetcli"]

rpm/nvmetcli.spec.tmpl:26

• python3 -m build uses PEP 517 build isolation by default and will try to pip install build requirements into a temp env. In distro package builds (often offline), this commonly fails. Use --no-isolation (and ensure build requirements are provided by BuildRequires/Build-Depends) to keep builds deterministic.

This issue also appears on line 30 of the same file.

%{__python3} -m build

debian/rules:14

• python3 -m build uses build isolation by default and will try to install build requirements via pip in a temporary env. With http_proxy set to block network access, this is likely to fail. Add --no-isolation and rely on Build-Depends to provide build requirements.

This issue also appears on line 17 of the same file.

	python3 -m build

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Suppressed comments (7)

debian/rules:17

• pip3 install may attempt dependency resolution / downloads and may use build isolation. Since the rules file explicitly blocks network access, add --no-deps --no-build-isolation --no-index to make the install step deterministic/offline.

	pip3 install --root=$(install_dir) --prefix=/usr .

rpm/nvmetcli.spec.tmpl:26

• python3 -m build defaults to build isolation, which may try to download build requirements during RPM builds (typically offline). Consider disabling isolation and relying on BuildRequires instead.

%{__python3} -m build

rpm/nvmetcli.spec.tmpl:30

• The %install step uses pip3 install ... ., which can trigger dependency resolution and rebuilds. Installing the wheel produced in %build with --no-deps --no-index --no-build-isolation is more deterministic and avoids network access.

pip3 install --root=%{buildroot} --prefix=usr .

rpm/nvmetcli.spec.tmpl:11

• pyproject.toml declares build-system requirements on setuptools and wheel, but the RPM BuildRequires list does not include distro packages for them. This can make offline builds fail if build isolation is disabled or if the build frontend cannot provision build requirements.

This issue also appears in the following locations of the same file:

• line 26
• line 30

BuildRequires:  python3-devel python3-pip python3-build systemd-units

debian/control:10

• debian/rules switches to --with python3, but debian/control still uses ${python:Depends}. With dh-python for Python 3, the substvar is ${python3:Depends}; leaving ${python:Depends} will typically result in missing runtime deps.

Depends: ${misc:Depends}, ${python:Depends}, python-configshell-fb

debian/rules:14

• python3 -m build defaults to build isolation, which can cause attempts to fetch build requirements. Since this packaging explicitly blocks network access, pass --no-isolation and rely on distro-provided build requirements instead.

This issue also appears on line 17 of the same file.

	python3 -m build

nvmet/nvme.py:293

• Falling back to modprobe when /proc/sys/kernel/modprobe exists but is empty changes behavior: an empty value is commonly used to disable module autoloading via modprobe. It’s safer to treat an empty file as “do not attempt to load modules” rather than falling back to modprobe.

        modprobe_cmd = 'modprobe'
        try:
            with open('/proc/sys/kernel/modprobe', 'r', encoding="utf-8") as f:
                modprobe_cmd = f.read().strip() or modprobe_cmd
        except OSError:

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated no new comments.

Suppressed comments (5)

debian/control:10

• debian/rules switches to dh ... --with python3, but debian/control still uses ${python:Depends}. With dh-python in Python 3 mode this substitution variable is not provided, which can break dependency generation. Consider also aligning the configshell dependency name with the Python 3 package in your distro.

Depends: ${misc:Depends}, ${python:Depends}, python-configshell-fb

debian/rules:18

• pip3 install during Debian package builds should be prevented from resolving/downloading dependencies and from creating an isolated build env (which can trigger network access). Add --no-deps --no-build-isolation and prefer python3 -m pip for consistency.

override_dh_auto_install:
	pip3 install --root=$(install_dir) --prefix=/usr .

rpm/nvmetcli.spec.tmpl:31

• In the RPM spec, pip3 install --prefix=usr uses a relative prefix, which can install files under an unexpected path. Also, RPM builds should avoid dependency resolution / build isolation to prevent network access and ensure reproducible builds.

%install
rm -rf %{buildroot}
pip3 install --root=%{buildroot} --prefix=usr .
mkdir -p %{buildroot}%{_sysconfdir}/nvmet

README:54

• Minor grammar: "simple run" should be "simply run".

coverage installed and simple run 'make test'.  To run all

nvmet/test_nvmet.py:31

• _usable_devices() can raise OSError/PermissionError from os.stat() even after os.path.exists() returns true (e.g., permission issues or races). Treat such paths as unusable instead of crashing the tests.

    return [x for x in NVMET_TEST_DEVICES
            if os.path.exists(x) and
            (stat.S_ISBLK(os.stat(x).st_mode) or os.path.isfile(x))]