ray-packages v2.52.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.

changes

• cheat on python runtime's python version to make things build with python 3.12;
• fixes the vendor grpc change;
• reorder the patches with a new round of format-patch .

[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]

we would like to remove the osx_64 (intel silicon) ones. we no longer release those, and the code might not work any more

[aslonnie]

linux build is failing with /bin/bash: line 6: unzip: command not found

[mattip]

/bin/bash: line 6: unzip: command not found

This is due to bazel's hermetic build isolation which removes conda's binaries from the path. We worked around this before which led to disabling strict path isolation in a patch. It seems you disabled that when redoing the patches. https://github.com/conda-forge/ray-packages-feedstock/pull/250/files#diff-6a5f2ea45e0f884f983e105370918f3da744786580a0cbac458c3a5b52fb095cR19

[aslonnie]

yeah, the patch name is changed by git..

[aslonnie]

seems mostly working; rerunning the one failed.

[aslonnie]

@mattip do you know what is the proper way to stop building osx_64 ones? just remove the related configs and files?

[mattip]

stop building osx_64

diff --git a/recipe/recipe.yaml b/recipe/recipe.yaml
index 8ec4973..d3a43a7 100644
--- a/recipe/recipe.yaml
+++ b/recipe/recipe.yaml
@@ -28,6 +28,7 @@ source:
 
 build:
   number: 0
+  skip: True  # [plat == osx_64]
 
 
 outputs:

[mattip]

Then rerender

[apmorton]

Those comments don't work for rattler. You want:

build:
  skip:
    - osx_64

followed by a rerender

[apmorton]

However, for the record, even though upstream doesn't support osx-64, we should keep building it until:

• it is not possible to do so without undue effort
• conda-forge officiall drops it

[aslonnie]

we should keep building it until

why? why build code that does not really work any more?

upstream already removed code logic related to intel silicon macos.

[apmorton]

There are a number of reasons outlined in the linked thread about why osx_64 support is still relevant to the conda-forge ecosystem but the most notable for the ray feedstock is that osx_arm64 is cross compiled, and as a result the tests are not run.

If you remove the osx_64 build there is zero osx test coverage for this feedstock, which is bad.
I'm unsure if emulated tests can be enabled on osx.

Clearly ray still works on osx_64 at a basic level, since the tests run a ray.init and aren't blowing up.

What specifically has been removed upstream?

[aslonnie]

osx_arm64 is cross compiled, and as a result the tests are not run.

this seems like a reasonable reason. can this be changed? should we try to change it? seems that changing this is a pre-condition of stop building osx_64?

What specifically has been removed upstream?

• some osx amd64 logic related to ray's runtime environment are removed.
• some build logic that are architecture+platform specific are not including osx amd64. for example, we do not have prebuilt redis binaries for osx amd64.
• python dependencies are starting to upgrade to versions that do not have osx amd64
• all CI for osx amd64 has been removed. there are no tests running on osx amd64 any more. as a result, code logic that needs to do different things for different arch+platform might ship without logic handling osx amd64 in general.

I am personally okay with keep building it given your reasoning, especially for this 2.52.x (as it already has everything passed.. I would prefer not needing to wait for another couple of hours to rebuild everything..), but in the long run, keep building it and shipping potentially broken things does not seem to be right thing to do? or maybe we can add a big warning when running import ray or ray.init() that says "osx amd64 is not supported, behavior is undefined, only use at your own risks"?

[apmorton]

https://devblogs.microsoft.com/devops/upcoming-updates-for-azure-pipelines-agents-images/?commentid=5134#comment-5134

"We expect to announce the Public Preview of MacOS ARM64 hosted agents in the coming weeks."

It seems like there is finally light at the end of this tunnel.

I would say lets just keep building osx_64 for the time being, and hopefully within a few months arm64 runners will become available to conda-forge.

[aslonnie]

lets just keep building osx_64 for the time being

ok. sg. I am clicking the merge button then.