Closed conda-forge-linter closed 2 years 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.
Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you but ran into some issues. Please check the output logs of the latest rerendering GutHub actions workflow run for errors. You can also ping conda-forge/core for further assistance or try re-rendering locally.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-ci-setup-feedstock/actions/runs/1872983473.
@conda-forge-admin rerender
ouch: - nvcc_linux-64=None
cc @jaimergp
I am missing a bit of context here. I guess this is to reduce the huge build matrix we had due to the CUDA versions and sync with conda-forge-pinning
?
Yes. We dropped 10.1 and now the versions are synced automatically.
@conda-forge-admin rerender
Smithy release is done.
Is this going to create many packages with the same build number, but different build strings (due to the introduction of cuda).
I think this is going to cause the solvers some real headaches with users flip flopping between equivalent releases.
We could/should bump the version to prevent this maybe.
The "solver headaches" ship has largely sailed now. The repodata is so big that optimizing exactly what builds we push in an effort to avoid solver issues is not going to yield a bunch of nice results IMHO.
From a user experience point of view, I often find myself (and people I explain to) confused by packages like:
removing version 1.23.45 build 0 hash 123456
installing version 1.23.45 build 0 hash 7890ABC
The solver in this case has no way to prefer one over the other, and I've found it to often flip flop between the two when I type:
mamba update --all --yes
I would like to avoid this flip flopping if we can. But maybe you are right and better testing is more important.
100% agreed! The version bump will avoid it. Given the changes here, I think it makes sense.
@conda-forge-admin rerender
Is conda-forge-ci-setup dependent on compilers('cuda')
that seems strange to me.
Yes. We install the windows cuda packages on the fly.
Got it. Then why not add cuda to the build string? Isnt that what we do for other packages?
Ahhhhh. So the cuda variants generate tests of the package during CI with cuda. At runtime, the cuda variant doesn't need to be matched AFAIK. We could prioritize the cuda None package by build number maybe to prevent the issue above. I think I've been not understanding you.
Right. I'm not sure what the best solution is. I would prefer to revert to the old way.
To test against different cuda variants, I would use a selector based on the python version.
That limits the number of outputs, but yet does a good job testing against different cuda variations.
I would prefer to revert to the old way.
You mean one build per platform and python version?
I would prefer to revert to the old way.
You mean one build per platform and python version?
Yes.
I bet the build number approach would be easier to maintain and will get us to the same result. If you want to make a separate PR for the other way, that is fine.
The purpose of this PR was only to make sure rerendering worked for the switch from master to main and to generate some builds on main.
Thus I think we should defer this improvement to another PR.
Any other comments @hmaarrfk @conda-forge/core or can we merge?
good for me.
FYI I opened an issue (#191).
@conda-forge-admin rerender
I'm testing the build number bump idea here to make sure it works. I can remove if we want to merge but I am feeling less comfortable merging than I was before.
Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-ci-setup-feedstock/actions/runs/1878334619.
@conda-forge-admin rerender
Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.
This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-ci-setup-feedstock/actions/runs/1878357031.
Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #189.
Here's a checklist to do before merging.
Fixes #189