Drop using setup_requires.

[icemac]

This is due to constant problems on GHA for MacOS leading to the error of a not empty directory during build if there is no wheel.

[icemac]

I am planning to release theses changes as a dev release as Python 3.12 support is currently not working. But it should unblock the building error on AccessControl.

[dataflake]

I'll keep my fingers crossed.

[dataflake]

To get the most realistic test you should only release a .tar.gz source release and not prebuild eggs. The dependent package must be forced to build its own wheel from that.

[mgedmin]

lgtm

[d-maurer]

Jens Vagelpohl wrote at 2023-4-18 23:28 -0700:

To get the most realistic test you should only release a `.tar.gz` source release and not prebuild eggs. The dependent package must be forced to build its own wheel from that.

I am not sure that this is sufficient. My analysis of the `ubuntu` test failure hints towards the following cause: Apparently, `setuptools` makes the assumption that any Python 3.12 wheel can be used. In the failure above, a prebuild wheel was used instead of a `git` checkout. And apparently, this wheel behaves different that the checkout. It might be necessary, to also delete the wheel on PyPI in addition to only release the source.

[d-maurer]

I think we still use a prebuilt wheel (dist/zope.security-6.2.dev0-cp312-cp312-linux_x86_64.whl) rather than the git checkout. I believe that this explains the different behavior between the GHA test and a local built.

I suggest to prevent the use of the wheel (even though I do not know how; maybe delete it on PyPI) and I hope that we will then get identical behavior between the GHA test and a local test (and maybe the ubuntu problem disappears).

[dataflake]

Dieter we are talking about two different things. I do not care about the Ubuntu error. I am only talking about wheels failing to build on macOS with the "directory not empty" error.

Example: https://github.com/zopefoundation/AccessControl/actions/runs/4730992430/jobs/8395395407

[icemac]

@d-maurer zope.security-6.2.dev0-cp312-cp312-linux_x86_64.whl is not on PyPI. The whole idea behind the GHA workflow to build the packages containing C code is to build the wheel in a first step and later on use that wheel to install it for the test run and to publish it to PyPI in case of a release commit.

[icemac]

@dataflake wrote:

To get the most realistic test you should only release a .tar.gz source release and not prebuild eggs. The dependent package must be forced to build its own wheel from that.

As the problem only occurs on Python 3.12, we are lucky with our current toolchain: it never releases a wheel for a future Python version as the ABI might not yet be stable and using a wheel created for an older ABI version will lead to a crash.

[icemac]

Thank you for reviewing this PR. 😃

[icemac]

Just released https://pypi.org/project/zope.security/6.2a1.dev0/ and re-started AccessControl build to use this release: https://github.com/zopefoundation/AccessControl/actions/runs/4751196569/jobs/8440094524

[dataflake]

Looks like copying the header files solves the macOS build issue. This whole song and dance trying to pre-install packages to get at the header files was just too fancy and error-prone.

[d-maurer]

Michael Howitz wrote at 2023-4-19 23:14 -0700:

@d-maurer `zope.security-6.2.dev0-cp312-cp312-linux_x86_64.whl` is not on PyPI. The whole idea behind the GHA workflow to build the packages containing C code is to build the wheel in a first step and later on use that wheel to install it for the test run and to publish it to PyPI in case of a release commit.

I have not seen a trace of the wheel building in the GHA output.

[dataflake]

I have not seen a trace of the wheel building in the GHA output.

Does it help if I confirm that this wheel does not exist on PyPI? It is built as part of the GHA action. I don't think it's important if you see specific output from this wheel build process. Rest assured, it is being built right then and there. It's not coming from PyPI.

[d-maurer]

Jens Vagelpohl wrote at 2023-4-19 23:45 -0700:

> I have not seen a trace of the wheel building in the GHA output. Does it help if I confirm that this wheel does not exist on PyPI?

No.

It is built as part of the GHA action. I don't think it's important if you see specific output from this wheel build process. Rest assured, it is being built right then and there. It's not coming from PyPI.

The corresponding test shows a persistent failure ("super class returned with an exception set") which indicates some code problem (in contrast to e.g. a race condition). This failure does not happen in a local test. In order to understand this behavior, I looked carefully at the GHA output. And I saw that the code used for the test did not come from a checkout but from a prebuilt wheel. In addition, the output did not provide a hint where this wheel came from. My hypothesis therefore has been that the wheel was outdated. Output corresponding to the wheel creation could have easily refuted this hypothesis. Its lack indicates at least a weakness in the GHA process. Do you have an idea why the test `test (3.12.0-alpha.7, ubuntu-20.04)` fails persistently on GHA with `SystemError: <class 'super'> returned a result with an exception set` while it locally succeeds or how to analyze this behavior?

[dataflake]

Let me repeat myself: We are talking about two entirely different problems here. You keep bringing up the Ubuntu test failure. That's not what I am concerned with right now at all. And it has nothing to do with the macOS wheel build issue. You keep confusing these two separate issues. The macOS wheel build issue that I am interested in seems to be fixed by the changes in this PR. The Ubuntu issue can be dealt with in a separate issue and a separate PR. So please let's stop this needless discussion.

[dataflake]

I have created a separate issue for the test failures at #99, all further discussions should happen there.