Henry Schreiner

> If PyPi could build the wheel automatically for pure Python packages This would be a mess; there [are pure Python packages](https://github.com/facelessuser/wcmatch) that depend on the Python version to generate...

> for instance `python -m wheel` generates wheels for dependencies for packages That's because this is being misused, you should use `build` instead, which does not generate extra packages, because...

> generates wheels for dependencies for packages with C extensions Not exactly, it generates wheels for any dependencies that do not have wheels already uploaded for your system. So if...

> Then ... needs updating I agree. And there is too much duplication in packaging.python.org, IMO... > So some logic that does the correct version filtering by default without relying...

Can someone open an issue in twine with the suggestion for the "smart" default, using `pep517.meta.load`, then?

We should look at what py-build-cmake does, as that is supported there. Maybe this would make more sense once we have an install command?

I believe adding `INSTALL_PREFIX ` to `configure_package_config_file` would fix it. Not sure why it's making the path absolute, it's supposed to use `CMAKE_INSTALL_PREFIX` to make it relative already.

```console # gh repo clone untwine/pxr-arch # cd pxr-arch # git checkout python-packaging # uv build --wheel # unzip dist/*.whl ``` Which file has the absolute path? All the files...

I believe the install location for the directories is configurable, so no, it's not predictable. I don't think you can even get a relative path between data and scripts, which...

I believe this is possible with dynamic-metadata (we need to work on finishing that project, actually, probably should be another "before 1.0" target). It's also something that comes up with...