bpo-26317: GH Action Test

[ax3l]

Add test coverage for macOS builds via free and fast GitHub Action runs:

• macOS 10.15 + AppleClang 11.0
• macOS 10.15 + Homebrew GCC (atm 9.3)

This needs the fix in #13306 to land first.

Refs.:

• bpo-26317: Build Problem with GCC + Macintosh OS X 10.11 El Capitain #13306 (fixes this error: https://github.com/ax3l/cpython/runs/612544626?check_suite_focus=true)
• https://bugs.python.org/issue26317

https://bugs.python.org/issue26317

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@ax3l

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

[ax3l]

ping @corona10 @ned-deily @terryjreedy
This PR provides free testing resources on macOS, both with AppleClang as well as GCC.

[ned-deily]

Thanks for the suggested PR, @ax3l, but we are not going to adopt it. Here's why. The time taken to perform the set of required CI tests is already too long for many developers. Adding another two will only lengthen that. And there's little reason to suppose that the additional tests will discover pre-integration problems that would not already be detected by the existing CI tests. Any problems unique to using GNU gcc on macOS would likely be with macOS-specific or -customary options, like options for universal builds and macOS SDKs or interaction with third-party Python pacakages, and we don't CI test for those kinds of things with the standard Apple-supplied compilers today anyway. But beyond that, even though the additional testing resources would not have a monetary cost to us (today, at least), there is the cost of using somewhat precious and generous testing resources provided for the whole open source community for something that will likely have little if any benefit. Sorry!

[ax3l]

Hi @ned-deily,
thank you for the feedback, let me correct a few things please:

The time taken to perform the set of required CI tests is already too long for many developers. Adding another two will only lengthen that.

These tests run in parallel to your travis-ci tests. The time for them to pass will be very similar and not added.

On top of that, you have significantly more parallel tests as well as more stability with GH actions, in case you ever wanted to test more.

And there's little reason to suppose that the additional tests will discover pre-integration problems that would not already be detected by the existing CI tests. Any problems unique to using GNU gcc on macOS would likely be with macOS-specific or -customary options, like options for universal builds and macOS SDKs or interaction with third-party Python pacakages, and we don't CI test for those kinds of things with the standard Apple-supplied compilers today anyway.

Definitely not and this is the perfect counter example: #13306
On macOS, CPython builds require as of today an Objective-C module and this is not declared in autotools. Only due to a specific quirk in AppleClang, this builds at all. You do not have GCC coverage on macOS and it's simple to add. Why don't we want to be able to build with an open source compiler on macOS?

there is the cost of using somewhat precious and generous testing resources provided for the whole open source community for something that will likely have little if any benefit. Sorry!

So all people that try to build CPython with GCC (and likely other compilers such as icc) on macOS just get stuck with a seemingly successful but broken install. They might spot a non-fatal error message in the build

 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: error: variably modified 'bytes' at file scope
   193 |  char bytes[kAuthorizationExternalFormLength];
       |       ^~~~~

but will otherwise see:

    from _scproxy import _get_proxy_settings, _get_proxies
ImportError: No module named _scproxy

when using CPython.

When I google the latter, user-facing error message: It shows a couple of thousand of results and is open since over ten years.

Shouldn't we consider the time wasted of users that tap into that? Their time is a precious resource, (little, free and automated) machine time for a very popular project is less precious. Sure, no need to run all the test again for every PR (make buildbottest), but at least we could add the compile itself and a quick subset of mini-checks to make sure that the python interpreter works at all.

Alternatively, one can also use these scripts for cpython release checks, e.g. you only run them once when opening release branches or tagging a version.

[terryjreedy]

I agree with not adding more CI for a minority use case. Even if the elaspsed time does not increase, the number of CI failures will increase, and in particular, the number of false positives with respect to particular PRs will increase. These are a damn nuisance. Even if the new test is optional, failures disable auto commits, which are normal for backports. Increased friction merging patches into CPython will directly results in fewer merges and indirectly increase pressure on unpaid core developers to reduce contribution time and do something else. The issue is not 'personal value of time' but impact on the total python community.

Many people expect that Apple will release Macs based on their proprietary Axx chips within a couple of years. I expect that this will be enough for Ned and other core python-on-Mac developers to contend with.

Testing an alternate build path on Mac seems like something that should be left to a buildbot, as it is on other platforms. I don't know it a buldbot could use the free external resources, but Axel could look into it.

[ax3l]

Hi Terry, can you please provide a bit more details on the latter paragraph? I am just not familiar with what you mean with a buildbot, I though that's what this is proposing: e.g. building this on release branches and RCs.

[terryjreedy]

See buildbot.python.org. I don't know if there is anything in the devguide or not, or any doc other than the site.