Drop Python 3.7 support and update meta templates #1214
Conversation
|
Possibly related: zopefoundation/meta#247 |
|
The errors are all a re-manifestation of buildout/buildout#609 and zopefoundation/meta#181. zc.buildout is broken when using it from a Python that has been compiled to use In the past we have worked around it by just excluding GHA tests for Python versions we know wouldn't work anymore. At this point, with newer macOS runners that are all using Nothing is broken for Python installs that are built for the native x86_64 or arm64 architecture. Just universal2. Not sure what to do right now. |
|
Jens Vagelpohl wrote at 2024-5-28 02:57 -0700:
The errors are all a re-manifestation of buildout/buildout#609 and zopefoundation/meta#181. zc.buildout is broken when using it from a Python that has been compiled to use `universal2` architecture on macOS because it has a really dumb algorithm to match the system architecture.
In the past we have worked around it by just excluding GHA tests for Python versions we know wouldn't work anymore. At this point, with newer macOS runners that are all using `universal2`, this isn't enough anymore. Unless we stop testing on macOS altogether.
Nothing is broken for Python installs that are built for the native x86_64 or arm64 architecture. Just universal2.
Not sure what to do right now.
One approach could be to fix `zc.buildout`.
When I remember right, then older `zc.buildout` versions delegated
to `easy_install` (at least I have seen this name often in tracebacks).
An upcoming `zc.buildout` could delegate to a modern installer
(e.g. `pip`) in the hope that this can cope with modern platforms.
|
|
Yes, fixing zc.buildout would be great. And making it not use easy_install. I wish someone would do that, I do not want to become a zc.buildout and/or setuptools maintainer myself. My latest thought was to try and switch the tox template to use pip and straight zope.testrunner instead of installing dependencies and building the convenience test script with buildout. Some of the configuration templates already do it that way. |
|
This PR uses changed meta templates from zopefoundation/meta#248 to work around the macOS issues. Local tox runs are not affected unless you manually add |
Co-authored-by: Michael Howitz <[email protected]>
|
Jens Vagelpohl wrote at 2024-5-29 09:00 -0700:
...
Because when pre-installing the additional packages in the universal2 environment the alltests script will point to the virtual environment's site-packages folder multiple times, which means all kinds of undesired tests are run (and fail). If you know a better solution I am all ears.
`zope.testrunner` already has the option `require-unique`.
This means that it maintains a structure able to detect (apparent) test
"duplicate"s.
It would be easy to use this structure to implement the option
`skip-test-duplicates` to not run a test with a test id already known.
|
The problem is not duplicate tests. The problem is that it tries to test everything in the virtual environment's site-packages, which doesn't work and is not the desired outcome. |
|
Jens Vagelpohl wrote at 2024-5-29 09:18 -0700:
> `zope.testrunner` already has the option `require-unique`. This means that it maintains a structure able to detect (apparent) test "duplicate"s. It would be easy to use this structure to implement the option `skip-test-duplicates` to not run a test with a test id already known.
The problem is not duplicate tests. The problem is that it tries to test everything in the virtual environment's site-packages, which doesn't work and is not the desired outcome.
Likely, there is a solution for this, too:
* Formerly, you could use "bin/instance test" to test packages
excluding standard ones.
It worked with a complex negative module filter, excluding
all modules which should not get tested
* Alternatively, we could try the option `ignore-dir`.
It tells the runner where not to look for tests.
|
|
If you want to specify folders to ignore there's the problem that you would need to synthesize what folders to ignore in the tox configuration. This is not a fixed value. It's the site-packages folder of the Python version that is being used to run the tests. Before spending too much time on this please consider what we're testing. The alltests script tests Zope plus an arbitrary selection of other packages. There's no real rhyme or reason to that selection of additional packages. And obviously those packages are all tested with Zope in their own package test configurations already. And the alltest script would only be replaced by the standard test script for macOS runners. So there's no real loss. The other runners will have tested this already. |
Creating as draft because of the macOS issues.