ray-packages v2.53.0

[aslonnie]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• 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.

[conda-forge-admin]

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/recipe.yaml) and found it was in an excellent condition.

[aslonnie]

the building is failing on python 3.10 with:

$SRC_DIR/conda_build.sh: line 8: 44211 Segmentation fault      (core dumped) python "$SRC_DIR/conda_build_script.py"

[aslonnie]

is it possible that this is causing the segfault?

[aslonnie]

I am reverting this libgrpc version change and giving it a try.

[aslonnie]

interestingly other python versions or other platforms do not seem to suffer from the same issue..

[timkpaine]

Note that libgrpc 1.71 would make this not useable with the latest broader conda forge ecosystem (and is thus to be avoided)

[aslonnie]

@timkpaine thanks. do you have any insight / suggestion about the segfault error, link here:

https://github.com/conda-forge/ray-packages-feedstock/actions/runs/20605393269/job/59187760974

[aslonnie]

seems that after the change linux64 python3.10 's segfault goes away..

I did not revert the ones for other python version or platforms.

@timkpaine , any suggestions on how to move forward?

cc @mattip too..

[aslonnie]

@timkpaine , are you a conda-forge ray package user yourself? may I ask which python version do you care about the most?

[aslonnie]

cc @h-vetinari and #253 too

[aslonnie]

I am a bit inclined to just merge it like this for now.. something is better than nothing I guess? and we can always patch later?

some other alternatives:

• skip 2.53.0, until the grpc lib version issue is root caused and fixed
• remove python 3.10 altogether, we will still have 3.11 and 3.12

[h-vetinari]

Please do not merge like this. Having different pins for py310 vs. the rest is not helpful, and the feedstock would become fragile to rerendering (which should be an operation that's always stable).

IMO the options are to either skip py310 or root-cause the issue (which is might be related to #90, though I don't know why it appears to be dependent on the python version; a plausible possibility is that some dependency stopped publishing for python 3.10 and so you're getting a qualitatively different environment for 3.10 vs. 3.11+)

[aslonnie]

ok.. let me revert the change and try to do some time-boxed debugging.. if I cannot figure out why, will file a PR to skip py310.

[aslonnie]

here is a PR without 3.10:
#255

not sure if running in parallel works or not, or if I need to increase the build number?

[h-vetinari]

not sure if running in parallel works or not, or if I need to increase the build number?

The second PR is unnecessary. Running in parallel wastes resources. Build numbers only matter once merged.

[h-vetinari]

I fixed this up manually before merging in 8580d1d + a rerender. I intentionally did not push to the PR again, because that would be one more wasted CI run for things that we already know are passing.