heh, now the test in gh-15647 seems to fail. Is it building with Accelerate masquerading as openblas or using lapack-lite?

The test is likely failing, because it is building with lapack_lite. With no explicit accelerate mentioned in the python script it does not search for it. On azure pipeline mac machine unlike my personal mac laptop, the default lapack does not link to accelerate, so the build, for the new test does not build with accelerate, hence the test passes(resulting in pipeline step failure ), since there is not import time issue as far as the pipeline is concerned.

I mentioned the above in
gh-15695

The solution is for the azure pipleine step testing for accelerate error, should be forced built with accelerate for it work on azure pipeline mac instance

Testing the branch on my local Mac continues to detect the issue (since the default lapack is a symlink to accelerate on my mac laptop)

 git branch
  mac_os_test
  master
* remove-accelerate2
(numpyenv) vrakesh$ python -c "import numpy as np"
python(32720,0x10529b5c0) malloc: can't allocate region
*** mach_vm_map(size=18446744072377757696) failed (error code=3)
python(32720,0x10529b5c0) malloc: *** set a breakpoint in malloc_error_break to debug
init_dgelsd failed init
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/rakvas/Workspace/numpy/numpy/__init__.py", line 287, in <module>
    raise RuntimeError(msg)
RuntimeError: Polyfit sanity test emitted a warning, most likely due to using a buggy Accelerate backend. If you compiled yourself, see site.cfg.example for information. Otherwise report this to the vendor that provided NumPy.
RankWarning: Polyfit may be poorly conditioned

(numpyenv) vrakesh$ 

I wonder why your machine has symlinks and the azure build machine does not. Did Azure remove something or did you (and @WarrenWeckesser, who also noticed the symlinks) somehow install something that created those links? Versions of Xcode?

On the other hand, maybe it is enough that gh-15695 showed that the test works, and now we can remove that CI run confident that anyone who still uses Accelerate via those symlinks will get the error.

I wonder why your machine has symlinks and the azure build machine does not. Did Azure remove something or did you (and @WarrenWeckesser, who also noticed the symlinks) somehow install something that created those links? Versions of Xcode?

I am not sure why either, but I ran a script on azure pipeline, to verify it. there is no symlink back to accelerate for the default lapack and blas implementation.

I am fine with disabling the test as well on pipelines or we could force the symlink ourselves, in the pipeline script (Though I would not prefer the second option, since it disturbs the preset environment)

@cournape do you still have questions? The GUI says "changes requested" but I think I related to all the review comments.

I have addressed @cournape 's comments. It would be nice to get this in before it once again goes stale and needs a rebase.

So this PR should wait until the test is improved, and then we can revisit removing the Accelerate-specific code.

Yes, the idea is that we do not want accelerate to be used either by intent or by accident.

Rather than repeat it here, I'll link to my comment on gh-15946.

Instead of continuing #15966, it seems simpler to add the simple check for a symlink to Accelerate to this PR. I created a branch in my repo that has one more commit on top of this PR: WarrenWeckesser@ac55699

I think that does what we want.

Thanks Matti and Warren! There seem to be some unaligned dot tests around, so I think fully deleting the test is just as well. Lets put this in, if anything comes up, we can fix it up.