use ci_requirements from numpy

[mattip]

Previously, this repo had its own, perhap different, requirements file for OpenBLAS. We should use the one from the NumPy we are building.

[mattip]

That failure is strange. It is in a test added for the OpenBLAS threading model on windows numpy/numpy#27036 and is now showing up on cp3.14 on windows. I don't see other failures of that test here, and don't remember failures in the numpy/numpy repo. The relevant change between the successful builds with scipy-openblas-0.3.30.0.2 and the failing build here with scipy-openblas-0.3.3.30.0.6 is patching OpenBLAS with threaded calls in numpy/numpy#29391, but that patch should only involve pthreads.

[mattip]

Hmm. The only windows runs we have in regular CI are

• a clang-cl python3.14t run with scipy-openblas32
• a msvc 32-bit python3.11 run without OpenBLAS
• a cygwin one with OpenBLAS from the cygwin distribution

[mattip]

Preserving the error here and rerunning the failed CI run

Preserve the error

  ================================== FAILURES ===================================
  ___________________ TestRegression.test_openblas_threading ____________________
  [gw2] win32 -- Python 3.14.0 C:\Users\runneradmin\AppData\Local\Temp\cibw-run-on526c25\cp314-win_amd64\venv-test\Scripts\python.exe
  
  self = <numpy.linalg.tests.test_regression.TestRegression object at 0x00000247E2C09D90>
  
      @pytest.mark.thread_unsafe(reason="test is already testing threads with openblas")
      def test_openblas_threading(self):
          # gh-27036
          # Test whether matrix multiplication involving a large matrix always
          # gives the same (correct) answer
          x = np.arange(500000, dtype=np.float64)
          src = np.vstack((x, -10 * x)).T
          matrix = np.array([[0, 1], [1, 0]])
          expected = np.vstack((-10 * x, x)).T  # src @ matrix
          for i in range(200):
              result = src @ matrix
              mismatches = (~np.isclose(result, expected)).sum()
              if mismatches != 0:
  >               assert False, ("unexpected result from matmul, "
                      "probably due to OpenBLAS threading issues")
  E               AssertionError: unexpected result from matmul, probably due to OpenBLAS threading issues
  E               assert False
  
  expected   = array([[-0.00000e+00,  0.00000e+00],
         [-1.00000e+01,  1.00000e+00],
         [-2.00000e+01,  2.00000e+00],
         ...99997e+06,  4.99997e+05],
         [-4.99998e+06,  4.99998e+05],
         [-4.99999e+06,  4.99999e+05]], shape=(500000, 2))
  i          = 0
  matrix     = array([[0, 1],
         [1, 0]])
  mismatches = np.int64(10069)
  result     = array([[ 0.00000e+00,  0.00000e+00],
         [-1.00000e+01,  1.00000e+00],
         [-2.00000e+01,  2.00000e+00],
         ...99997e+06,  4.99997e+05],
         [-4.99998e+06,  4.99998e+05],
         [-4.99999e+06,  4.99999e+05]], shape=(500000, 2))
  self       = <numpy.linalg.tests.test_regression.TestRegression object at 0x00000247E2C09D90>
  src        = array([[ 0.00000e+00, -0.00000e+00],
         [ 1.00000e+00, -1.00000e+01],
         [ 2.00000e+00, -2.00000e+01],
         ...99997e+05, -4.99997e+06],
         [ 4.99998e+05, -4.99998e+06],
         [ 4.99999e+05, -4.99999e+06]], shape=(500000, 2))
  x          = array([0.00000e+00, 1.00000e+00, 2.00000e+00, ..., 4.99997e+05,
         4.99998e+05, 4.99999e+05], shape=(500000,))
  
  ..\venv-test\Lib\site-packages\numpy\linalg\tests\test_regression.py:181: AssertionError

[mattip]

Rerunning the CI job passed, indicating the test is flaky.

[rgommers]

As I think I've said before (#6 (comment)), I didn't do this on purpose - it feels like (a) it's the wrong way around, and (b) this installs more dependencies than we need to (spin, click) in almost all CI jobs. And a generically-named file like ci_requirements.txt is not unlikely to get even more packages added to it over time.

If we want to auto-sync these, the better approach is probably to:

• take a single job in the main repo and make that clone this repo
• check (on PRs to the main branch only) openblas_requirements.txt vs. ci_requirements.txt version numbers are equal or the ones in openblas_requirements.txt are higher, and fail if that's not the case.
  • then, to bump the version, this repo has to be updated first, so it can't go out of date
  • custom_checks is probably the right job: https://github.com/numpy/numpy/blob/0fdb1979cdfcdd31b61f423b66a384fabd1d7fd7/.github/workflows/linux.yml#L323

[rgommers]

Hmm. The only windows runs we have in regular CI are

There are 7 active Windows jobs, 3 non-wheel and 2 wheel build jobs on GHA and 2 on Azure. The Cygwin one was disabled early this year.

[rgommers]

If we want to auto-sync these, the better approach is probably to:

I'm happy to implement this later today if that helps

[mattip]

Ok, closing

[mattip]

Changing the name of ci_requirements.txt is a good idea