Skip to content

Handle warning about private API and pybind11 before 2.0.0rc1 #26010

Closed
@rgommers

Description

@rgommers

In 2.0.0b1 we still have a very verbose and scary-looking warning like this:

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.0.dev0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled against NumPy 2.0.
...
pybind11 note: You may see this message if using pybind11,
this is not problematic at pre-release time
it indicates the need for a new pybind11 release.

Full warning:

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.0.dev0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled against NumPy 2.0.

If you are a user of the module, the easiest solution will be to
either downgrade NumPy or update the failing module (if available).

NOTE: When testing against pre-release versions of NumPy 2.0
or building nightly wheels for it, it is necessary to ensure
the NumPy pre-release is used at build time.
The main way to ensure this is using no build isolation
and installing dependencies manually with NumPy.
For cibuildwheel for example, this may be achieved by using
the flag to pip:
    CIBW_BUILD_FRONTEND: pip; args: --no-build-isolation
installing NumPy with:
    pip install --pre --extra-index-url https://pypi.anaconda.org/scientific-python-nightly-wheels/simple
in the `CIBW_BEFORE_BUILD` step.  Please compare with the
solutions e.g. in astropy or matplotlib for how to make this
conditional for nightly wheel builds using expressions.
If you do not worry about using pre-releases of all
dependencies, you can also use `--pre --extra-index-url` in the
build frontend (instead of build isolation).
This will become unnecessary as soon as NumPy 2.0 is released.

If your dependencies have the issue, check whether they
have nightly wheels build against NumPy 2.0.

pybind11 note: You may see this message if using pybind11,
this is not problematic at pre-release time
it indicates the need for a new pybind11 release.

We need to finalize this before 2.0.0rc1 in one of two ways:

  1. Turn the warning into a hard error,
  2. Silence the warning.

At #25918 (comment) we discussed a bit. @seberg said:
"That huge warning is seems only semi-useful, it would be nice to make it a hard error by the time we release, otherwise we don't protect users from potentially bad results/crashes due to a module that wasn't recompiled. I don't care much about rc1 specifically it just seems like a plausible/reasonable warning shot for pybind11."

I said: "Well, it must be done either before rc1 or not at all. The way it looks now, it actually seems fairly safe to disable the warning, leaving the compat shim in place for 2.0, and make it a hard error on main in a month or so. Probably best to wait and see how a pybind11 release is coming along, and decide in a week or so?"

The outcome will depend on pybind/pybind11#5009. If pybind11 manages to get a release out soon enough, we may be able to turn the warning into an error. If not, then it'll be too disruptive to do so.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions