Disable multi-core pyiron table test for mac os x

[jan-janssen]

This fixes the broken Mac OS X tests.

[jan-janssen]

While I hoped introducing the with-statement in #1384 would fix the issue - it does not. So I temporarily disable the corresponding test.

[liamhuber]

This fixes the broken Mac OS X tests.

It hides them, it doesn't fix them.

If we can check for the system and pass in the tests, we can check for the system and fail cleanly with an informative error message (and then test for that case) in the codebase itself. This also doesn't truly "fix" the problem either, but at least it puts the code in an understood state.

[jan-janssen]

It hides them, it doesn't fix them.

Yes, because I think a partially working test on Mac OS X is more valuable than no test on Mac OS X and partially in this case means, all but one.

[liamhuber]

It hides them, it doesn't fix them.

Yes, because I think a partially working test on Mac OS X is more valuable than no test on Mac OS X and partially in this case means, all but one.

I'm not advocating that we should bail on OSX here, I'm saying instead of skipping the test and leaving users to discover some weird hang state lets fix it so it fails clean! Then the tests will be passing because they return a known state, that is, failure on OSX for this particular operation.

In the long run, of course, we want the parallel operation working on OSX too, but since nobody seems to have any clue how to accomplish that, let the codebase reflect it!

[jan-janssen]

In the long run, of course, we want the parallel operation working on OSX too, but since nobody seems to have any clue how to accomplish that, let the codebase reflect it!

It is just a single feature that is not working on OSX. This pull request localises the issues. So the test for this feature is skipped by marking the corresponding test. For me this is a totally different statement, than saying pyiron_base is not working on Mac OS X. Consequently, I am still I favour of merging this pull request, especially as nobody else had the time to look into this issue in the last three weeks, so I do not see anybody having the time to fix it soon.

[liamhuber]

Ok, I try one more time: there is a feature that we know will break for users under certain conditions, but it won't fail cleanly or in an informative way. We know this because the CI whines to us with a red flag. You have nailed down exactly the part of the code that is failing and isolated it with a flag.

Now use that flag to give the user an informative error (and catch that error using the same flag in the tests) instead of using it to tell the CI to just shut up.

I don't understand why this is even a fight. Of course we both want the tests passing. You've already done all the necessary sleuthing and almost all the necessary leg work for catching the issue cleanly for users. Why just leave the code with a dirty break??

[jan-janssen]

Locally everything works fine - it is a Github CI specific issue. I now added the workaround in #1390 and opened an issue with the Github Images team actions/runner-images#9534 .