Open ytausch opened 3 months ago
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.
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.
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.
Thought we are open to trying better solutions ( https://github.com/regro/cf-scripts/issues/2531#issuecomment-2155641154 )?
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
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.
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?
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.
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
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.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)~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 https://github.com/regro/cf-scripts/issues/2531#issuecomment-2194496927
If this is approved, I will also create PRs at our other LLVM repos.