+1 for this idea. I'd like to treat f2py compile tests similarly to Mypy tests - a couple of dedicated jobs, and disabled everywhere else. Proposed config:

• 1 Windows job, MSVC/gfortran on py311 (for now, could switch to Flang or LFortran at some point)
• 2 Linux jobs, gcc/gfortran, for lowest and highest supported Python versions
• 1 macOS job, clang/gfortran

This is the output of spin test -- numpy/f2py/ --durations=25 right now:

========================================================================== slowest 25 durations ==========================================================================
4.19s call     numpy/f2py/tests/test_compile_function.py::test_f2py_init_compile[]
4.14s call     numpy/f2py/tests/test_compile_function.py::test_f2py_init_compile[--noopt --debug]
4.02s call     numpy/f2py/tests/test_compile_function.py::test_f2py_init_compile[extra_args0]
3.38s setup    numpy/f2py/tests/test_kind.py::TestKind::test_int
2.92s setup    numpy/f2py/tests/test_mixed.py::TestMixed::test_all
2.53s setup    numpy/f2py/tests/test_abstract_interface.py::TestAbstractInterface::test_abstract_interface
2.43s setup    numpy/f2py/tests/test_module_doc.py::TestModuleDocString::test_module_docstring
2.34s setup    numpy/f2py/tests/test_callback.py::TestF77CallbackPythonTLS::test_all[t]
2.33s setup    numpy/f2py/tests/test_isoc.py::TestISOC::test_c_double
2.33s setup    numpy/f2py/tests/test_return_real.py::TestFReturnReal::test_all_f77[t0]
2.29s setup    numpy/f2py/tests/test_common.py::TestCommonWithUse::test_common_gh19161
2.27s setup    numpy/f2py/tests/test_return_integer.py::TestFReturnInteger::test_all_f77[t0]
2.24s setup    numpy/f2py/tests/test_character.py::TestStringOptionalInOut::test_gh24662
2.24s setup    numpy/f2py/tests/test_crackfortran.py::TestUnicodeComment::test_encoding_comment
2.24s setup    numpy/f2py/tests/test_character.py::TestCharacterString::test_input[1]
2.23s setup    numpy/f2py/tests/test_quoted_character.py::TestQuotedCharacter::test_quoted_character
2.21s setup    numpy/f2py/tests/test_crackfortran.py::TestDimSpec::test_array_size[n]
2.21s setup    numpy/f2py/tests/test_callback.py::TestF77Callback::test_all[t]
2.21s setup    numpy/f2py/tests/test_return_complex.py::TestFReturnComplex::test_all_f77[t0]
2.20s setup    numpy/f2py/tests/test_callback.py::TestGH18335::test_gh18335
2.20s setup    numpy/f2py/tests/test_f2cmap.py::TestF2Cmap::test_long_long_map
2.19s setup    numpy/f2py/tests/test_string.py::TestFixedString::test_intent_in
2.18s setup    numpy/f2py/tests/test_character.py::TestMiscCharacter::test_gh18684
2.18s setup    numpy/f2py/tests/test_data.py::TestDataF77::test_data_stmts
2.18s setup    numpy/f2py/tests/test_crackfortran.py::TestNoSpace::test_module
================================================== 762 passed, 9 skipped, 36 deselected, 3 xfailed in 114.32s (0:01:54)

That should all be disabled in the default test runs, it's way too expensive. EDIT: the above is with gh-25111, it's better on main - but still taking almost a minute on macOS arm64.

Hi Everyone,

Greetings!
I hope you all are doing well. Is this issue still unresolved I am interested in working on this issue.

Thanks and Regards

Hi @ojuschugh1, yes this still needs doing and would be helpful. I think it can be done without crossing paths with @HaoZeke's gh-25252, so should be fine to work on now.

I'd suggest:

1. looking at how we test with MyPy (e.g., the mypy.yml workflow file and the RUN_MYPY environment variable),
2. Iterating on this on your own fork, so you're running only the new CI jobs, and only opening a PR to this repo once the new jobs work

Hi @rgommers ,

Thanks for the prompt response. Sure, I would be happy to work on this :D.

Thanks and Regards

Hi @rgommers ,

Thanks for the prompt response. Sure, I would be happy to work on this :D.

Thanks and Regards

Thanks for taking a look at this, let me know if you'd like to setup a meet to go over parts of the CI and what would be needed.

Hi @HaoZeke ,

Thank you for your support. Sure, I will definitely contact you if I face any trouble.

Thanks again for this nice gesture.

Thanks and Regards,
Ojus Chugh

Hello @HaoZeke ,
Greetings for the day. I hope you are doing great. I apologize for the delay. I wanted to work on this issue - [https://github.com//issues/25134]. I have forked the NumPy repo. Could you kindly help me set this up locally on my PC tomorrow if you have some time? Thanks for the help. I look forward to hearing from you soon. :)
Thanks and Regards.

Thanks @HaoZeke for your prompt response. I will certainly try to follow the documentation and set up the system. Let's plan to meet on Friday at 10 pm IST[ if that's okay with you ] to discuss this bug further and address any doubts I might have encountered.

I've also messaged you on Slack. We can discuss further details there as well.

Thanks and regards

OK this came up again (#26703, #26706), so I took a closer look, and one other thing to keep track of is that the NumPy Azure set uses vsenv, while the supported configuration discussed in #25073 (comment) deals with the rtools stack, like SciPy, which doesn't use the same linker...

So basically:

• We need instructions to work with --vsenv and f2py (likely the quadmath thing will not be needed)
• A working CI for F2PY on Windows
  • I'm veering towards biting the bullet and fixing this, the Azure set can continue with vsenv but we can have a separate GHA for the rtools tests, and to have a group just for F2PY compiled modules (which shouldn't be run very often at all)

This would lead to roughly the same set of configurations @rgommers already mentioned, so this is just more context reinforcing that :)

I'm not sure if --vsenv is critical here, since irrespective of MSVC vs. MinGW compilers for C/C++ we're always using gfortran I believe. If it helps, two Windows jobs seems fine to me of course. Just not sure either way if it adds much value - unless we use ifx or flang-new with MSVC?

I'm not sure if --vsenv is critical here, since irrespective of MSVC vs. MinGW compilers for C/C++ we're always using gfortran I believe. If it helps, two Windows jobs seems fine to me of course. Just not sure either way if it adds much value - unless we use ifx or flang-new with MSVC?

OTOH it seems to change the linker used (hence the quadmath failure on Azure), but I'll confirm on a Windows machine.