Bump to 3.1.0

[mgorny]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

---

Managed to unvendor LLVM and make it build against LLVM 19 but it fails to run:

: CommandLine Error: Option 'print-pipeline-passes' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

I've seen it before, I'll think about it more tomorrow. I still need to unvendor NVidia dependencies too.

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

For recipe/meta.yaml:

• ℹ️ No valid build backend found for Python recipe for package triton using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

[mgorny]

Ok, so the problem with LLVM is that the build system somehow manages to simultaneously link to static and shared LLVM libraries, which results in duplicate symbols. My quick attempt to use just shared libraries fails, so instead I need to figure out where the shared libraries are coming from.

[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.

[mgorny]

A quick summary (roughly the same details as in comments and commit messages):

• Unvendoring is done via environment variables read by setup.py. *_SYSPATH vars are used to locate stuff, CUDA-related vars don't seem to be used, beyond disabling downloads when they are defined.
• I've had to backport a few upstream changes to make the package compatible with LLVM 19 release. Otherwise, it requires LLVM from a mainline commit between 18 and 19.
• I've had to patch the build system not to link LLVM static libraries. It's linking static MLIR libraries which whose CMake exports have dependencies on LLVM shared library. As a result, both the static and shared libraries are used simultaneously, which leads to breakage.
• I've had to switch to newer CUDA, as I've had build failures with 12.0. Upstram uses 12.4.99, I went straight for 12.6.
• I've tested the resulting package against PyTorch 2.5.1, using this example: https://pytorch.org/tutorials/intermediate/torch_compile_tutorial.html. I've confirmed that torch.utils._triton.has_triton() evaluates to True (it did with PyPI-installed triton, it did not with the old version from conda-forge), and that nvcc is invoked.

[mgorny]

CC @isuruf @hmaarrfk @danpetry

[h-vetinari]

This looks very good already, thanks a lot. Some questions

[h-vetinari]

Thank you very much!

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[mgorny]

Thanks!