Merge pull request #3 from regro-cf-autotick-bot/rebuild-numpy2-0-1_h…

…ed4782

Rebuild for numpy 2.0

.ci_support/linux_64_numpy1.22python3.10.____cpython.yaml → .ci_support/linux_64_numpy2.0python3.10.____cpython.yaml

@@ -9,7 +9,7 @@ c_stdlib_version:
 cdt_name:
 - cos6
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +19,7 @@ cxx_compiler_version:
 docker_image:
 - quay.io/condaforge/linux-anvil-cos7-x86_64
 numpy:
-- '1.22'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/linux_64_numpy1.23python3.11.____cpython.yaml → .ci_support/linux_64_numpy2.0python3.11.____cpython.yaml

@@ -9,7 +9,7 @@ c_stdlib_version:
 cdt_name:
 - cos6
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +19,7 @@ cxx_compiler_version:
 docker_image:
 - quay.io/condaforge/linux-anvil-cos7-x86_64
 numpy:
-- '1.23'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/migrations/numpy2.yaml

@@ -0,0 +1,74 @@
+__migrator:
+  build_number: 1
+  kind: version
+  commit_message: |
+    Rebuild for numpy 2.0
+    
+    TL;DR: The way we build against numpy has changed as of numpy 2.0. This bot
+    PR has updated the recipe to account for the changes (see below for details).
+    The numpy 2.0 package itself is currently only available from a special release
+    channel (`conda-forge/label/numpy_rc`) and will not be available on the main
+    `conda-forge` channel until the release of numpy 2.0 GA.
+    
+    The biggest change is that we no longer need to use the oldest available numpy
+    version at build time in order to support old numpy version at runtime - numpy
+    will by default use a compatible ABI for the oldest still-supported numpy versions.
+    
+    Additionally, we no longer need to use `{{ pin_compatible("numpy") }}` as a
+    run requirement - this has been handled for more than two years now by a
+    run-export on the numpy package itself. The migrator will therefore remove
+    any occurrences of this.
+    
+    However, by default, building against numpy 2.0 will assume that the package
+    is compatible with numpy 2.0, which is not necessarily the case. You should
+    check that the upstream package explicitly supports numpy 2.0, otherwise you
+    need to add a `- numpy <2` run requirement until that happens (check numpy
+    issue 26191 for an overview of the most important packages).
+    
+    Note that the numpy release candidate promises to be ABI-compatible with the
+    final 2.0 release. This means that building against 2.0.0rc1 produces packages
+    that can be published to our main channels.
+    
+    If you already want to use the numpy 2.0 release candidate yourself, you can do
+    ```
+    conda config --add channels conda-forge/label/numpy_rc
+    ```
+    or add this channel to your `.condarc` file directly.
+    
+    ### To-Dos:
+      * [ ] Match run-requirements for numpy (i.e. check upstream `pyproject.toml` or however the project specifies numpy compatibility)
+        * If upstream is not yet compatible with numpy 2.0, add `numpy <2` upper bound under `run:`.
+        * If upstream is already compatible with numpy 2.0, nothing else should be necessary in most cases.
+        * If upstream requires a minimum numpy version newer than 1.19, you can add `numpy >=x.y` under `run:`.
+      * [ ] Remove any remaining occurrences of `{{ pin_compatible("numpy") }}` that the bot may have missed.
+    
+    PS. If the build does not compile anymore, this is almost certainly a sign that
+    the upstream project is not yet ready for numpy 2.0; do not close this PR until
+    a version compatible with numpy 2.0 has been released upstream and on this
+    feedstock (in the meantime, you can keep the bot from reopening this PR in
+    case of git conflicts by marking it as a draft).
+
+  migration_number: 1
+  exclude:
+    # needs local overrides that get stomped on by the migrator, which then fails
+    - scipy
+    # already done, but thinks its unsolvable
+    - pandas
+  ordering:
+    # prefer channels including numpy_rc (otherwise smithy doesn't
+    # know which of the two values should be taken on merge)
+    channel_sources:
+      - conda-forge
+      - conda-forge/label/numpy_rc,conda-forge
+
+# needs to match length of zip {python, python_impl, numpy}
+# as it is in global CBC in order to override it
+numpy:
+  - 1.22  # no py38 support for numpy 2.0
+  - 2.0
+  - 2.0
+  - 2.0
+  - 2.0
+channel_sources:
+  - conda-forge/label/numpy_rc,conda-forge
+migrator_ts: 1713572489.295986

.ci_support/osx_64_numpy1.22python3.10.____cpython.yaml → .ci_support/osx_64_numpy2.0python3.10.____cpython.yaml

@@ -1,5 +1,7 @@
 MACOSX_DEPLOYMENT_TARGET:
 - '10.13'
+MACOSX_SDK_VERSION:
+- '10.13'
 c_compiler:
 - clang
 c_compiler_version:
@@ -9,7 +11,7 @@ c_stdlib:
 c_stdlib_version:
 - '10.13'
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +21,7 @@ cxx_compiler_version:
 macos_machine:
 - x86_64-apple-darwin13.4.0
 numpy:
-- '1.22'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/osx_64_numpy1.23python3.11.____cpython.yaml → .ci_support/osx_64_numpy2.0python3.11.____cpython.yaml

@@ -1,5 +1,7 @@
 MACOSX_DEPLOYMENT_TARGET:
 - '10.13'
+MACOSX_SDK_VERSION:
+- '10.13'
 c_compiler:
 - clang
 c_compiler_version:
@@ -9,7 +11,7 @@ c_stdlib:
 c_stdlib_version:
 - '10.13'
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +21,7 @@ cxx_compiler_version:
 macos_machine:
 - x86_64-apple-darwin13.4.0
 numpy:
-- '1.23'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/osx_arm64_numpy1.22python3.10.____cpython.yaml → .ci_support/osx_arm64_numpy2.0python3.10.____cpython.yaml

@@ -1,5 +1,7 @@
 MACOSX_DEPLOYMENT_TARGET:
 - '11.0'
+MACOSX_SDK_VERSION:
+- '11.0'
 c_compiler:
 - clang
 c_compiler_version:
@@ -9,7 +11,7 @@ c_stdlib:
 c_stdlib_version:
 - '11.0'
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +21,7 @@ cxx_compiler_version:
 macos_machine:
 - arm64-apple-darwin20.0.0
 numpy:
-- '1.22'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/osx_arm64_numpy1.23python3.11.____cpython.yaml → .ci_support/osx_arm64_numpy2.0python3.11.____cpython.yaml

@@ -1,5 +1,7 @@
 MACOSX_DEPLOYMENT_TARGET:
 - '11.0'
+MACOSX_SDK_VERSION:
+- '11.0'
 c_compiler:
 - clang
 c_compiler_version:
@@ -9,7 +11,7 @@ c_stdlib:
 c_stdlib_version:
 - '11.0'
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
@@ -19,7 +21,7 @@ cxx_compiler_version:
 macos_machine:
 - arm64-apple-darwin20.0.0
 numpy:
-- '1.23'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/win_64_numpy1.22python3.10.____cpython.yaml → .ci_support/win_64_numpy2.0python3.10.____cpython.yaml

@@ -3,13 +3,13 @@ c_compiler:
 c_stdlib:
 - vs
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
 - vs2019
 numpy:
-- '1.22'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x

.ci_support/win_64_numpy1.23python3.11.____cpython.yaml → .ci_support/win_64_numpy2.0python3.11.____cpython.yaml

@@ -3,13 +3,13 @@ c_compiler:
 c_stdlib:
 - vs
 channel_sources:
-- conda-forge
+- conda-forge/label/numpy_rc,conda-forge
 channel_targets:
 - conda-forge main
 cxx_compiler:
 - vs2019
 numpy:
-- '1.23'
+- '2.0'
 pin_run_as_build:
   python:
     min_pin: x.x