search

conda-forge / conda-forge-ci-setup-feedstock

A conda-smithy repository for conda-forge-ci-setup.
BSD 3-Clause "New" or "Revised" License
13 stars 51 forks source link

MNT: rerender #190

Closed conda-forge-linter closed 2 years ago

conda-forge-linter commented 2 years ago

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

conda-forge-linter commented 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.

github-actions[bot] commented 2 years ago

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.

beckermr commented 2 years ago

@conda-forge-admin rerender

beckermr commented 2 years ago

ouch: - nvcc_linux-64=None

jakirkham commented 2 years ago

cc @jaimergp

jaimergp commented 2 years ago

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?

beckermr commented 2 years ago

Yes. We dropped 10.1 and now the versions are synced automatically.

beckermr commented 2 years ago

@conda-forge-admin rerender

beckermr commented 2 years ago

Smithy release is done.

hmaarrfk commented 2 years ago

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.

beckermr commented 2 years ago

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.

hmaarrfk commented 2 years ago

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.

beckermr commented 2 years ago

100% agreed! The version bump will avoid it. Given the changes here, I think it makes sense.

beckermr commented 2 years ago

@conda-forge-admin rerender

hmaarrfk commented 2 years ago

Is conda-forge-ci-setup dependent on compilers('cuda') that seems strange to me.

beckermr commented 2 years ago

Yes. We install the windows cuda packages on the fly.

hmaarrfk commented 2 years ago

Got it. Then why not add cuda to the build string? Isnt that what we do for other packages?

beckermr commented 2 years ago

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.

hmaarrfk commented 2 years ago

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.

beckermr commented 2 years ago

I would prefer to revert to the old way.

You mean one build per platform and python version?

hmaarrfk commented 2 years ago

I would prefer to revert to the old way.

You mean one build per platform and python version?

Yes.

beckermr commented 2 years ago

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.

beckermr commented 2 years ago

Any other comments @hmaarrfk @conda-forge/core or can we merge?

hmaarrfk commented 2 years ago

good for me.

beckermr commented 2 years ago

FYI I opened an issue (#191).

beckermr commented 2 years ago

@conda-forge-admin rerender

beckermr commented 2 years ago

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.

github-actions[bot] commented 2 years ago

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.

beckermr commented 2 years ago

@conda-forge-admin rerender

github-actions[bot] commented 2 years ago

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.