ENH: update package version to 13.3.0

[conda-forge-admin]

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

I've started a version update as instructed in #190.

I'm currently searching for new versions and will update this PR shortly if I find one! Thank you for waiting!

Fixes #190

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

  • For the test.requires section of <output 0 output, you should usually use the pin python {{ python_min }} for the python entry.

• If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.
• ℹ️ cuda-python output overrides versions pinned in the feedstock:
  ['- In section host: python 9999.*']
  Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26546120428. Examine the logs at this URL for more detail.}

[rwgk]

@conda-forge-admin, please restart ci

[rwgk]

PR 191 failure analysis: stale conda-forge repodata

Summary

The restarted CI is no longer blocked by missing uploaded CUDA 13.3 packages in the Anaconda package API. However, the new Linux failures still show that the build solver cannot see cuda-profiler-api 13.3.27 in conda-forge repodata yet.

The failure is happening while conda-build finalizes metadata for cuda-bindings, before any actual build or test step:

Getting pinned dependencies: ...working... failed
Unsatisfiable dependencies for platform linux-64:
  {MatchSpec("cuda-version[version='>=12.0,<12.1.0a0']"),
   MatchSpec("cuda-profiler-api==12.0.76=ha770c72_0")}

Encountered problems while solving:
  - package cuda-profiler-api-12.0.76-ha770c72_0 requires cuda-version >=12.0,<12.1.0a0,
    but none of the providers can be installed
...
cuda-version =13.3 * is not installable because it conflicts with any installable versions previously reported.

The solver's candidate list for cuda-profiler-api only goes up to 13.2.75; it does not list 13.3.27.

Repodata check

The Anaconda package API shows the expected cuda-profiler-api 13.3.27 files uploaded and labeled main:

linux-64/cuda-profiler-api-13.3.27-h7938cbb_0.conda
linux-aarch64/cuda-profiler-api-13.3.27-h16bee8c_0.conda
win-64/cuda-profiler-api-13.3.27-h57928b3_0.conda

But the solver-visible conda-forge repodata URLs did not yet include those records:

https://conda.anaconda.org/conda-forge/linux-64/repodata.json
https://conda.anaconda.org/conda-forge/linux-aarch64/repodata.json
https://conda.anaconda.org/conda-forge/win-64/repodata.json

This explains the apparent mismatch: package files exist, but CI uses repodata for solving, and that repodata has not caught up yet.

Windows failures

The Windows Azure jobs failed earlier, during checkout:

Git fetch failed with exit code: 128

That looks separate and likely transient, probably related to restarting CI while the bot closed/reopened the PR and the refs/pull/191/merge ref was moving. I would not treat this as a recipe problem unless it reproduces after repodata catches up.

Recommendation

No recipe change is recommended based on these logs.

Wait until cuda-profiler-api-13.3.27 appears in conda-forge repodata for all target subdirs, then restart CI again:

@conda-forge-admin, please restart ci

Watch command

Use this to watch the solver-visible repodata:

for subdir in linux-64 linux-aarch64 win-64; do
  echo "== $subdir =="
  curl -fsSL "https://conda.anaconda.org/conda-forge/$subdir/repodata.json" \
    | jq -r '((.packages // {}) + (."packages.conda" // {})) | keys[] | select(test("^cuda-profiler-api-13\\.3"))'
done

Expected output once repodata has caught up:

== linux-64 ==
cuda-profiler-api-13.3.27-h7938cbb_0.conda
== linux-aarch64 ==
cuda-profiler-api-13.3.27-h16bee8c_0.conda
== win-64 ==
cuda-profiler-api-13.3.27-h57928b3_0.conda

[rwgk]

@conda-forge-admin, please restart ci

[rwgk]

PR 191 CI failure analysis: cuda-pathfinder missing from build environment

Summary

The latest PR 191 CI failures are no longer caused by stale conda-forge repodata for cuda-profiler-api.

The previously missing package is now present in solver-visible conda-forge repodata for all relevant subdirs:

== linux-64 ==
cuda-profiler-api-13.3.27-h7938cbb_0.conda
== linux-aarch64 ==
cuda-profiler-api-13.3.27-h16bee8c_0.conda
== win-64 ==
cuda-profiler-api-13.3.27-h57928b3_0.conda

The restarted jobs now solve CUDA 13.3 dependencies correctly and proceed into the actual cuda-bindings build. The common failure across Linux and Windows is now:

ModuleNotFoundError: No module named 'cuda.pathfinder'

ModuleNotFoundError: cuda-pathfinder is not installed in the build environment.
Ensure 'cuda-pathfinder>=1.5' is in build-system.requires.

ERROR: Failed building wheel for cuda-bindings

Evidence

Representative Linux job:

cuda-version:      13.3-hcbadf70_3      conda-forge
cuda-profiler-api: 13.3.27-h7938cbb_0   conda-forge

The job then fails while running pip install . --no-deps -vv for the cuda-bindings output:

File ".../work/cuda_bindings/build_hooks.py", line 43, in _import_get_cuda_path_or_home
  import cuda.pathfinder
ModuleNotFoundError: No module named 'cuda.pathfinder'

Representative Windows Azure jobs show the same failure mode during build_output.bat, after checkout and dependency solve succeeded.

Root Cause

cuda-bindings 13.3.0 uses a PEP 517 build backend that imports
cuda.pathfinder from cuda-pathfinder.

The released upstream metadata requires it for builds:

cuda_bindings/pyproject.toml:
[build-system]
requires = [
    ...
    "cuda-pathfinder>=1.5",
]

The feedstock recipe currently lists cuda-pathfinder >=1.1.0,<2 only in the cuda-bindings runtime requirements:

requirements:
  run:
    - python
    - cuda-pathfinder >=1.1.0,<2

That makes cuda-pathfinder available to users after installation, but not to the isolated build environment used while building the wheel. Because the feedstock build script invokes:

$PYTHON -m pip install . --no-deps -vv

the build-time dependency must be supplied by conda-build through the output's host requirements.

Recommendation

This now needs a recipe change, not another wait-and-retry.

Add cuda-pathfinder >=1.5,<2 to the cuda-bindings output requirements.host, likely near the Python build tools:

requirements:
  host:
    - cython
    - pip
    - pyclibrary
    - python
    - setuptools
    - setuptools-scm >=8
    - cuda-pathfinder >=1.5,<2

Keeping the existing runtime dependency is still appropriate, but it should probably also be tightened to at least the upstream runtime metadata for 13.3.0:

requirements:
  run:
    - cuda-pathfinder >=1.4.2,<2

After updating the recipe, rerender if needed and restart CI:

@conda-forge-admin, please restart ci

[rwgk]

@kkraus14 @rparolin, @acosmicflamingo

EDIT 25 minutes later: see comment #191 (comment) below.

This is finally working. However, we also need a 12.9.7 Conda release, which is made from the same feedstock. We are switching between v12 and v13 recipes (e.g. the the 12.9.6 release was made from commit c9e9660). To only have one back-and-forth switch, I'll try to do the 12.9.7 release first, then 13.3.0. — If I run into time-consuming issues with the 12.9.7 release I'll backtrack and do this one first anyway.

[rwgk]

@kkraus14 @rparolin @acosmicflamingo

In the meantime I figured out that this PR targets main, but the 12.9.7 PR #194 targets 12.9, so there isn't a conflict.

I'll merge this PR now. (I'll also edit my previous comment to avoid misunderstandings in the future.)