numpy v1.26.2

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Closes: #302

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows a discrepancy between it and the the package's stated requirements in the meta.yaml.

Packages found by source code inspection but not in the meta.yaml:

• click
• packaging
• pygobject
• pyproject-metadata
• urllib3
• gitpython
• toml
• meson-python
• pygithub
• pytest
• cython
• numba
• pyinstaller
• sphinx
• nox
• beautifulsoup4
• git-versioner
• spin
• cffi
• coverage
• meson
• paver
• typing_extensions
• docutils
• numpydoc

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/6845296584, please use this URL for debugging.}

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

It seems we're having problems with pip on all cross-compiled architectures:

Successfully built numpy-1.26.2-cp311-cp311-linux_aarch64.whl
+ pip install dist/numpy-1.26.2-cp311-cp311-linux_aarch64.whl
ERROR: numpy-1.26.2-cp311-cp311-linux_aarch64.whl is not a supported wheel on this platform.

[mbargull]

For some reason pip (, setuptools, wheel) have been installed into the build environment.
I'll investigate why.

[mbargull]

@conda-forge-admin, please rerender

[mbargull]

For some reason pip (, setuptools, wheel) have been installed into the build environment. I'll investigate why.

This is an issue with conda-libmamba-solver and some legacy code in conda.plan that only conda-build uses which leads to add_pip_as_python_dependency: false being ignored.
I'll open an issue for conda-libmamba-solver.

[mbargull]

@conda-forge-admin, please rerender

[mbargull]

@conda-forge-admin, please rerender

[mbargull]

It's probably not rerendering due to https://www.githubstatus.com/incidents/x39xrr5m11b3

[mbargull]

win win_64_numpy1.22python3.9.____73_pypypython_implpypy failed test setups with
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=828185&view=logs&j=5be07ae1-d8ba-5406-47b6-8e3a3a12f825&t=c94d5231-acfc-5e67-dafc-77bdd383ead4&l=2940

________________ ERROR at setup of test_is_timedelta64_object _________________
[gw0] win32 -- Python 3.9.18 %PREFIX%\python.exe

tmp_path = WindowsPath('C:/Users/VssAdministrator/AppData/Local/Temp/pytest-of-VssAdministrator/pytest-0/popen-gw0/test_is_timedelta64_object0')

    @pytest.fixture
    def install_temp(tmp_path):
        # Based in part on test_cython from random.tests.test_extending
        if IS_WASM:
            pytest.skip("No subprocess")
    
        srcdir = os.path.join(os.path.dirname(__file__), 'examples', 'cython')
        build_dir = tmp_path / "build"
        os.makedirs(build_dir, exist_ok=True)
        try:
            subprocess.check_call(["meson", "--version"])
        except FileNotFoundError:
            pytest.skip("No usable 'meson' found")
        if sys.platform == "win32":
            subprocess.check_call(["meson", "setup",
                                   "--buildtype=release",
                                   "--vsenv", str(srcdir)],
                                  cwd=build_dir,
                                  )
        else:
            subprocess.check_call(["meson", "setup", str(srcdir)],
                                  cwd=build_dir
                                  )
>       subprocess.check_call(["meson", "compile", "-vv"], cwd=build_dir)

build_dir  = WindowsPath('C:/Users/VssAdministrator/AppData/Local/Temp/pytest-of-VssAdministrator/pytest-0/popen-gw0/test_is_timedelta64_object0/build')
srcdir     = 'D:\\bld\\numpy_1700564714692\\_test_env\\lib\\site-packages\\numpy\\core\\tests\\examples\\cython'
tmp_path   = WindowsPath('C:/Users/VssAdministrator/AppData/Local/Temp/pytest-of-VssAdministrator/pytest-0/popen-gw0/test_is_timedelta64_object0')

..\_test_env\lib\site-packages\numpy\core\tests\test_cython.py:54: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

popenargs = (['meson', 'compile', '-vv'],)
kwargs = {'cwd': WindowsPath('C:/Users/VssAdministrator/AppData/Local/Temp/pytest-of-VssAdministrator/pytest-0/popen-gw0/test_is_timedelta64_object0/build')}
retcode = 2, cmd = ['meson', 'compile', '-vv']

    def check_call(*popenargs, **kwargs):
        """Run command with arguments.  Wait for command to complete.  If
        the exit code was zero then return, otherwise raise
        CalledProcessError.  The CalledProcessError object will have the
        return code in the returncode attribute.
    
        The arguments are the same as for the call function.  Example:
    
        check_call(["ls", "-l"])
        """
        retcode = call(*popenargs, **kwargs)
        if retcode:
            cmd = kwargs.get("args")
            if cmd is None:
                cmd = popenargs[0]
>           raise CalledProcessError(retcode, cmd)
E           subprocess.CalledProcessError: Command '['meson', 'compile', '-vv']' returned non-zero exit status 2.

cmd        = ['meson', 'compile', '-vv']
kwargs     = {'cwd': WindowsPath('C:/Users/VssAdministrator/AppData/Local/Temp/pytest-of-VssAdministrator/pytest-0/popen-gw0/test_is_timedelta64_object0/build')}
popenargs  = (['meson', 'compile', '-vv'],)
retcode    = 2

..\_test_env\Lib\subprocess.py:373: CalledProcessError
---------------------------- Captured stdout setup ----------------------------
1.3.0

The Meson build system

Version: 1.3.0

Source dir: %PREFIX%\Lib\site-packages\numpy\core\tests\examples\cython

Build dir: C:\Users\VssAdministrator\AppData\Local\Temp\pytest-of-VssAdministrator\pytest-0\popen-gw0\test_is_timedelta64_object0\build

Build type: native build

Project name: checks

Project version: undefined

Activating VS 17.8.0

C compiler for the host machine: gcc (gcc 12.2.0 "gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 12.2.0")

C linker for the host machine: gcc ld.bfd 2.39

Cython compiler for the host machine: cython (cython 3.0.5)

Host machine cpu family: x86_64

Host machine cpu: x86_64

Program python3 found: YES (%PREFIX%\python.exe)

Run-time dependency python found: YES 3.9

Build targets in project: 1



checks undefined



  User defined options

    buildtype: release

    vsenv    : true



Found ninja-1.11.1 at %PREFIX%\Library\bin\ninja.EXE



Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper:

%PREFIX%\Scripts\meson compile -C .

Activating VS 17.8.0

INFO: automatically activated MSVC compiler environment

INFO: autodetecting backend as ninja

INFO: calculating backend command to run: %PREFIX%\Library\bin\ninja.EXE -v

Traceback (most recent call last):

  File "%PREFIX%\lib\site-packages\mesonbuild\mesonmain.py", line 194, in run

    return options.run_func(options)

  File "%PREFIX%\lib\site-packages\mesonbuild\mcompile.py", line 389, in run

    p, *_ = mesonlib.Popen_safe(cmd, stdout=sys.stdout.buffer, stderr=sys.stderr.buffer, env=env)

AttributeError: 'NoneType' object has no attribute 'buffer'



ERROR: Unhandled python exception



    This is a Meson bug and should be reported!

(No idea why sys.stdout/sys.stderr would be None; but I also haven't looked into this either.)

---

linux-aarch64 tests failed for

• TestCholesky.test_basic_property[float32-shape3]
• TestCholesky.test_basic_property[float32-shape4]
  https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=828185&view=logs&j=2ed0550f-e734-5ebf-52c6-1bfc19f5811c&t=324162ab-5352-5970-af17-18e5067e8284&l=2143

(As always: If someone can run these tests natively, we could preclude emulation issues before looking further.)

[rgommers]

@mattip maybe you'd be able to run that PyPy on Windows test with Meson 1.3.0, or know why sys.stdout/stderr would be None?

[mattip]

why sys.stdout/stderr would be None

I have seen this before when running under pytest + pypy + windows. I don't remember where. I can try to reproduce locally, but maybe it would be prudent to skip these tests on PyPy.

[mbargull]

why sys.stdout/stderr would be None

I have seen this before when running under pytest + pypy + windows. I don't remember where. I can try to reproduce locally, but maybe it would be prudent to skip these tests on PyPy.

Thanks Matti.
If it's too much hassle, we can skip those, yes.
Another thing one could try is to use stdout=subprocess.PIPE for those subprocess.check_calls to ensure those subprocesses get valid handles.

---

As for the linux-aarch64 builds, we could try to re-run those with newer QEMU binaries once we have those available (PR at conda-forge/docker-images#246).

[isuruf]

Not needed anymore after the last commit.

[mbargull]

Does that mean the cross-python stuff injects itself by overwriting the host's python or something?

[isuruf]

Yes

[mbargull]

Ah, ok.
Would it be sensible to let it overwrite ${BUILD_PREFIX}/bin/pip too (if it exists)?

(Yes, I know about the bonkers "we explicitly give you a pip executable, but you should actually only ever use python -m pip" thing people say and I don't agree for obvious reasons.)

[mbargull]

Let's rather continue to discuss that at conda-forge/cross-python-feedstock#76 .

[h-vetinari]

The following in the win+pypy failures looks suspect:

Activating VS 17.8.0
C compiler for the host machine: gcc (gcc 12.2.0 "gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 12.2.0")
C linker for the host machine: gcc ld.bfd 2.39

Actually, we're currently not setting up a C-compiler for the tests on windows, so I guess that's why it picks up the gcc from the image. Perhaps something changed about how this detection is done in meson 1.3? Not sure though why this works on CPython.

[h-vetinari]

I've restarted the builds now that we have openblas 0.3.25 available (recalling that the switch from 0.3.23 to 0.3.24 surfaced the apparent emulation problems, it could have been that 0.3.25 changes behaviour again), but the result is the same. I guess we should try the QEMU update...

[mattip]

Perhaps something changed about how this detection is done in meson 1.3?

I would expect this to show up upstream, but it seems that so far Numpy wheel CI runs with windows + pypy use meson 1.3.0 and pass tests. It is hard to see whether the tests that fail here pass there.

[mbargull]

Perhaps something changed about how this detection is done in meson 1.3?

I would expect this to show up upstream, but it seems that so far Numpy wheel CI runs with windows + pypy use meson 1.3.0 and pass tests. It is hard to see whether the tests that fail here pass there.

This shouldn't be related to meson=1.3 since the previous tests for the numpy=1.26.0 builds also failed using meson=1.2.2:

• numpy v1.26.0 with meson #297 (comment)
• https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=787023&view=logs&j=533b006e-c27f-58a3-8df4-b5a79e785988&t=dc82b8eb-3b6c-5509-52ae-84b71f43ad83&l=2205

---

Restarting the build with the new container images that have QEMU 8
@conda-forge-admin, please restart ci

[mbargull]

ARM builds still failing as before.

---

linux-aarch64 tests failed for

• TestCholesky.test_basic_property[float32-shape3]
• TestCholesky.test_basic_property[float32-shape4]
  https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=829098&view=logs&j=2ed0550f-e734-5ebf-52c6-1bfc19f5811c&t=324162ab-5352-5970-af17-18e5067e8284&l=2143

(As always: If someone can run these tests natively, we could preclude emulation issues before looking further.)

[h-vetinari]

I think for numpy it's OK to skip two tests. The issue is larger in scipy where we have 60 apparently spurious failures...

[h-vetinari]

@conda-forge-admin, please rerender

(just confirming that this doesn't cause further change; already verified locally)

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/numpy-feedstock/actions/runs/6978161822.