Henry Schreiner

Thanks! I'm going to try to work through some issues and get a new release out in a week or two. Just checking the first error: > fatal error: Python.h:...

Files (I'd really not call them dependencies) are controlled by setuptoools. So you'll want a `MANIFEST.in` and you can exclude/include things there. In scikit-build-core, you'd instead have include/exclude fields in...

Most of the errors seem to be related to not having permissions to create directories. The warnings are known and will/are being addressed in scikit-build-core.

We do not [support pytest 7.2 yet](https://github.com/scikit-build/scikit-build/blob/88fafd7943037f1ff57efb53d3b0c8e3d66455f8/requirements-dev.txt#L7). Pytest 7.2 added a new warning about returning from a test function that we can't ignore because it doesn't exist in the last...

Just curious, do you see any potential problems supporting [scikit-build-core](https://github.com/scikit-build/scikit-build-core)? That's the direction we are moving, and eventually it will even be the backend for scikit-build classic.

Sure, the log would help. I think you uploaded the wrong log in https://github.com/scikit-build/scikit-build/issues/753#issuecomment-1323800225 - it doesn't have nearly as many failures as the text in the comment, and there...

Do you know why the install directory is unwritable? That would fix most of the originally failing tests.

Ahh, that's probably what it is. I've been mostly working on scikit-build-core, which only uses PEP 517, which goes through the wheel mechanism. Something to keep in mind as I...

Do you have the full log with the unraisable exceptions in it?

The unraisable warning is `ResourceWarning: subprocess ... is still running`, from what I can tell. Any idea why that might be showing up for you but not in the normal...