gnuradio: migrate to python@3.9

[fxcoudert]

Follow-up of #62560
gnuradio bottle was missing on all 3 CI nodes, for reasons undetermined

[fxcoudert]

Test is failing, and bottle is not being archived.

==> python3 /private/tmp/gnuradio-test-20201023-50122-7ackp8/test.py
Traceback (most recent call last):
  File "/private/tmp/gnuradio-test-20201023-50122-7ackp8/test.py", line 1, in <module>
    from gnuradio import blocks
ModuleNotFoundError: No module named 'gnuradio'

[MikeMcQuaid]

Test is failing, and bottle is not being archived.

The bottle is probably not being archived because the test is failing. The test should be removed if it doesn't work.

[fxcoudert]

The bottle is probably not being archived because the test is failing

I'd argue that's not something we want: we regularly have tests that fail due to network flukes, and we want to be able to merge them without rebuilding everything if we know it's only a network fluke on one of the runners.

Also, if I could download the bottle I'd be able to debug what's wrong without having to rebuild on my own system. That's a very useful feature.

[SMillerDev]

Maybe we could always upload the artifacts by a different name for debugging? I don't think I've seen network flukes in tests for a long time so I'm less worried about those.

[jonchang]

I wonder if we actually want to move this back to python 3.7. Macports (which the gnuradio mac maintainer actually also maintainers) moved to py37 after seeing problems with gr. macports/macports-ports@c7fc6dd. This may address some of the issues we've seen around gnuradio.

[fxcoudert]

gnuradio has a lot of indirect python dependencies in its chain, so it can't easily be moved to an older version.

[fxcoudert]

First, there is an issue with python3 path in the test…

Once I fix it, locally I get:

$ /usr/local/opt/python@3.9/bin/python3 -c 'import numpy; print(numpy.__path__); print(numpy.dtype(numpy.int32))'
_NamespacePath(['/usr/local/lib/python3.9/site-packages/numpy'])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: module 'numpy' has no attribute 'dtype'

This happens because numpy is not being linked, and which in turn happens because:

$ brew link --overwrite --dry-run numpy
Would remove:
/usr/local/bin/f2py
/usr/local/bin/f2py3

This may be a local issue on my own cellar. We'll see what CI says…

[BrewTestBot]

@fxcoudert has triggered a merge.

[MikeMcQuaid]

I'd argue that's not something we want: we regularly have tests that fail due to network flukes, and we want to be able to merge them without rebuilding everything if we know it's only a network fluke on one of the runners.

We should remove tests that fail due to network flukes.

[MikeMcQuaid]

Something that is relevant to both here and Homebrew/brew#8980 (so I'll repeat myself in both): the goal is to have a Homebrew/homebrew-core that (eventually) requires green CI for all PRs to be merged. This is the case on this repository (and, frankly, most repositories) and would be better for both a contributor understanding and security perspective.