PyPi Wheel Generation

[amd-juwillia]

No description provided.

[adam360x]

This is where my code is failing to run in the container. Once we get this fixed I will approve as the rest looks great

[adam360x]

This is unrelated to this PR, did you have a stray commit in here? I think we'd want to have this separate.

[marbre]

Agreed.

[marbre]

I took a brief look myself and furthermore let an agent scan through this. As pointed out earlier this will need a written-down RFC before going further with the implementation. Here are some of the comments my agent left:

---

Python Wheel Version Tagging

The package has no C extension modules — no ext_modules, no cython, no cffi. libamd_smi_python.so is a C++ shared library bundled as package_data, not as a Python extension. pyproject.toml.in and setup.cfg.in both confirm this. Setuptools builds packages with no C extensions as py3-none-linux_x86_64 — Python version agnostic.

The manylinux workflow loops over six interpreters (cp38–cp313), but because the wheel tag is py3-none-linux_x86_64 for all of them, each iteration produces a file with the same name. Successive builds overwrite each other in $RAW_WHEELS. The "six wheels" outcome advertised by the workflow is not what actually happens.

auditwheel was designed for ABI-tagged wheels (cpXX-cpXX-linux_x86_64). Its behavior on py3-none-linux_x86_64 wheels that bundle .so data files is not well-defined and may produce incorrect tags, refuse the input, or pass it through unchanged.

Metadata Duplication:

Both files setup.cfg.in and pyproject.toml.in exist on the branch and both declare the full package metadata (name, version, author, classifiers, etc.). With setuptools ≥ 61, pyproject.toml takes precedence, but having two authoritative metadata sources creates a maintenance hazard: a version bump that updates one but not the other silently produces stale metadata.

CI / Workflow

• rpm-test now needs: [manylinux-build, debian-test]. This creates a cross-platform serialization: RPM tests cannot start until all Debian matrix legs complete (Ubuntu20, Ubuntu22, Ubuntu24, Debian10). Previously the RPM build was independent. With continue-on-error: true on Debian legs this may not block execution, but it increases total wall time.

• Manylinux gate hardcodes /opt/python/cp38-cp38/bin/python3. If manylinux_2_28 drops cp38 support in a future image update, the gate permanently breaks.

• chmod 777 "$WHEEL_OUT" in manylinux-build.yml is overly broad for a container build artifact directory.

[marbre]

What is the reason for not moving this to a dedicated scripts?

[marbre]

Why cat perf test results here instead of uploading them to a more accessible location?

[marbre]

Agreed.

[marbre]

As an additional note, I don't quite follow why you try to leverage .pth files which should be limited to a minimum:

https://docs.python.org/3/library/site.html

Note An executable line in a .pth file is run at every Python startup, regardless of whether a particular module is actually going to be used. Its impact should thus be kept to a minimum. The primary intended purpose of executable lines is to make the corresponding module(s) importable (load 3rd-party import hooks, adjust PATH etc). Any other initialization is supposed to be done upon a module’s actual import, if and when it happens. Limiting a code chunk to a single line is a deliberate measure to discourage putting anything more complex here.

Rather see https://www.debian.org/doc/packaging-manuals/python-policy/#module-path. Debian use this even though it is not standard, check how RPM-based distros handle it. As above, this needs a written down plan.