build and publish a wheel

[dimbleby]

All installation in python is from wheel: so if maintainers do not publish wheels then every user install must begin by building one.

That has a few (minor) disadvantages: it is slower, it is a thing that can go wrong. Security-conscious users will not want to run arbitrary code at install time.

Therefore best practice - even for pure python projects - is to publish both sdist and also wheel.

[buddly27]

Unfortunately, this module cannot be distributed as a wheel in a practical way.

On installation, it dynamically generates a CMake config-file package to bind pytest-cmake to the actual pytest version installed on the system using a custom hook, so that the generated PytestConfigVersion.cmake must reflect the local runtime environment.

If we were to publish a wheel, the PytestConfigVersion.cmake file would be frozen at build time, which would hard-code the latest pytest version into the wheel. That would defeat the purpose of the package and break compatibility for users running a different pytest version at install time.

> cd pytest-cmake/
> python -m build --wheel .
> unzip -Z1 dist/*.whl
...
pytest_cmake-1.2.0.data/data/share/Pytest/cmake/FindPytest.cmake
pytest_cmake-1.2.0.data/data/share/Pytest/cmake/PytestAddTests.cmake
pytest_cmake-1.2.0.data/data/share/Pytest/cmake/PytestConfig.cmake
pytest_cmake-1.2.0.data/data/share/Pytest/cmake/PytestConfigVersion.cmake

In this example, the PytestConfigVersion.cmake created would use pytest v9, even if the system uses pytest v8

> unzip -p dist/*.whl pytest_cmake-1.2.0.data/data/share/Pytest/cmake/PytestConfigVersion.cmake
...
set(PACKAGE_VERSION "9.0.2")
...

> pytest --version
pytest 8.4.1

[dimbleby]

I see. That probably suggests that this is work you should be doing at runtime rather than at install time, but perhaps that is a bigger change.

Eg pip install today will build and cache a wheel, using some specific pytest version. But if I create a new project tomorrow: I can get a different version of pytest and the same cached wheel.

[dimbleby]

Additionally: wheel building uses an isolated virtual environment. There is no guarantee that the pytest used to build the wheel matches the pytest in a user environment.

I expect that the wheel will typically build with the latest pytest, regardless of what version the user has in their own project.

[buddly27]

Ok, so I was completely wrong. The pytest version is actually fetched dynamically by the FindPytest.cmake module, and the PytestConfigVersion.cmake file isn’t needed at all!

We only generate a PytestConfig.cmake so CMake can discover the package, since CMake’s search procedure only looks for config files, not modules. But since that config file simply includes the module, CMake enters config mode for discovery while relying on the module for the actual logic. I somehow assumed that a static PytestConfigVersion.cmake would still be required for version checking, but it turns out that as long as the module sets VERSION_VAR, the entire version check can be fully dynamic.

So TL;DR, yes, publishing a wheel absolutely makes sense!

I’m currently on paternity leave, so it may take me a few days to update the installation process within your MR, I'll probably do it this weekend. Thanks for catching this!