Add cuda-cccl conflict with thrust/cub packages. #428
Conversation
|
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 ( |
|
cc: @kkraus14 |
|
Output of |
|
EDIT: This is because the cub / thrust packages changed how they handled their dependencies vs constrains with regards to each other at the time. This is fine. |
|
Thanks @kkraus14! |
|
@kkraus14 Right now |
Was also confused about this and had to dig further to understand what was going on. AIUI Since some packages have Anyways hopefully this makes it clearer for anyone else stumbling upon this and looking for more context |
Archiving the repo doesn't remove or mark the existing packages as broken as far as I'm aware. It just makes it clear that no future changes will happen to the recipe and no further packages will be produced. See: https://conda-forge.org/docs/maintainer/updating_pkgs.html#archiving-feedstocks |
|
For what it's worth, I think it's safe to archive the repos for thrust/cub. We can adapt the conda-forge |
|
Let's go ahead and fix those feedstocks since the usual process is fix the feedstock and then add a repodata patch with link to the PR fixing the feedstock As to archiving them, could someone please follow this process to archive feedstocks? |
@bdice It's confusing. Could you try this search instead? |
|
And please do the same check for |
Well sometimes I was asked to do it differently, but anyway @bdice has kindly sent fixes: |
|
@leofang Good find. Apparently I searched with these queries (thrust, cub) and found the following packages depending on thrust or cub. I can confirm @leofang's findings above.
Probably no significant action/migration is needed here. Archival and dependence on existing versions should be fine. I can leave issues on those feedstocks to notify their maintainers of the change, once it is ready. |
|
Yup. Or we can create a migrator for doing the work for us, once cccl is up. This would ensure the entire CF infra does not use |
|
Yeah think since |
| new_constrains = record.get('constrains', []) | ||
| new_constrains.append("cuda-cccl <0.0.0a0") | ||
| new_constrains.append("cuda-cccl-impl <0.0.0a0") | ||
| new_constrains.append(f"cuda-cccl_{subdir} <0.0.0a0") |
There was a problem hiding this comment.
Why do you need this? This package does not conflict
There was a problem hiding this comment.
You're correct that the thrust/cub packages don't clobber files in cuda-cccl_{subdir} (which installs to targets/.../include). They only clobber cuda-cccl-impl and cuda-cccl. However, I left this in because @kkraus14 suggested it, and it might not be a good idea to allow thrust/cub to be installed together with CUDA 12 packages. The thrust/cub versions shipped on conda-forge are not up-to-date, and don't have official support for CUDA 12. Meanwhile, cuda-cccl_{subdir} is specific to CUDA 12. I would be comfortable saying this is an unsupported case that would fall in the same bucket as cudatoolkit (CUDA 11) not being installable at the same time as cuda-nvcc_{subdir} (CUDA 12) despite not clobbering files (to my knowledge). What do you think?
Checklist
python show_diff.pyand posted the output as part of the PR. (see below)