Revert to using Maintainer-Provided sources, configure the bot to only use the RawURL Version Source

[ytausch]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged) I did not bump the build number as the output should not change.
• 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.

Configuring the bot to only use the RawURL version updater should allow us to use the maintainer-provided sources again, which has some benefits as GitHub-generated source tarballs are sometimes unstable.

See regro/cf-scripts#2531 (comment)

If this is approved, I will also create PRs at our other LLVM repos.

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

I really don't see the benefit of this (for me it has more disadvantages if anything), but if other people really prefer it like this, I won't stand in the way. 🤷‍♂️

I can already say though that the moment the bots start failing to issue update PRs again across the LLVM stack, this will be reverted, because right now it works without issue.

[ytausch]

I really don't see the benefit of this (for me it has more disadvantages if anything), but if other people really prefer it like this, I won't stand in the way. 🤷‍♂️

Just to be clear: I am not a strong advocate of this either because the GitHub-generated tarballs really work most of the time and we are adding complexity with this. But since @jakirkham mentioned the benefits of using the maintainer-provided sources and I don't really have to say anything against them, we should at least give it a try.

I can already say though that the moment the bots start failing to issue update PRs again across the LLVM stack, this will be reverted, because right now it works without issue.

Yes, absolutely.

[jakirkham]

Thought we are open to trying better solutions ( regro/cf-scripts#2531 (comment) )?

If so, then yes let's try this

If it doesn't work, we are just back where we started. And if it does, great we have found a reasonable solution

[h-vetinari]

Thought we are open to trying better solutions ( regro/cf-scripts#2531 (comment) )?

I'm open, despite considering it a worse solution which requires churn and introduces further drain on attention ("did it work?"), because it's not a discussion I consider worth spending time on. Feel free to merge if the change is important to you.

[jakirkham]

We can try it on one feedstock to start (could be this one or could be a different one)

That way we have comparative data between the current and new approach

Would that be easier to keep tabs on?

[h-vetinari]

We can try it on one feedstock to start (could be this one or could be a different one)

Fine by me. I'd prefer it to be another feedstock, because this one absolutely needs to be built the earliest, otherwise no other pieces of the LLVM stack can be built (so missing llvmdev is kinda the worst-case scenario in terms of missed bot PRs). So one of the later packages in the stack like lldb, mlir-python-bindings would be a good choice, otherwise lld or openmp would work too.

[jakirkham]

Great let's do mlir-python-bindings then. Didn't see any packages in conda-forge that depend on it. So hopefully that makes it lower risk

[h-vetinari]

Going to turn this into a draft while we wait and see how the experiment with mlir-python-bindings works out. There won't be another release before LLVM 19.1.0 in September, so we have a little while to wait.