Updated build recipe and patches to ray-1.3.0

[gshimansky]

Signed-off-by: Gregory Shimansky gregory.shimansky@intel.com

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

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.

[gshimansky]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.

[h-vetinari]

Would like to have @vnlitvinov's sign-off as well, but overall LGTM (did not verify the dependency changes with upstream, nor review the redis patch).

[h-vetinari]

I feel we should be setting those entry points in the appropriate sub-packages.

[vnlitvinov]

either that (if they need special requirements and those subpackages provide those) or allow them be in ray-core

[gshimansky]

This patch is taken verbatim from ray-1.2.0, no changes done to how these subpackages were handled in version 1.2.0
https://github.com/conda-forge/ray-packages-feedstock/blob/master/recipe/patches/0005-Disable-making-non-core-entry-scripts.patch

[vnlitvinov]

I've added serve entry point to ray-serve. I suggest keeping ray-operator removed for now as it's unclear to which package it should belong. We can wait for someone coming and raising an issue I think :)

[h-vetinari]

Thanks for working on this @gshimansky!

[h-vetinari]

Ping @vnlitvinov
Would love to still have your input, otherwise merging in ~24h.

[gshimansky]

@h-vetinari @vnlitvinov is currently on vacations and probably will answer only on the next week.

[h-vetinari]

@gshimansky: @vnlitvinov is currently on vacations and probably will answer only on the next week.

OK, thanks for the info. One thing that would make me much more comfortable in merging this is if we were running the test suite on the build - see #5. If you could tackle that as well, it would be amazing. 🙃

[gshimansky]

@h-vetinari yes you are right, using Ray tests to verify the build would be great. I saw #5 and will keep it in mind.

[vnlitvinov]

LGTM, I will be happy when the comment about separate entrypoints is addressed.

[vnlitvinov]

either that (if they need special requirements and those subpackages provide those) or allow them be in ray-core

[h-vetinari]

This needs a merge or rebase to fix the build_num back to 0.

Otherwise LGTM, thanks!

[gshimansky]

This needs a merge or rebase to fix the build_num back to 0.

Isn't it 0 already? https://github.com/conda-forge/ray-packages-feedstock/pull/14/files#diff-f3725a55bf339595bf865fec73bda8ac99f283b0810c205442021f29c06eea9aR27

[h-vetinari]

Isn't it 0 already? https://github.com/conda-forge/ray-packages-feedstock/pull/14/files#diff-f3725a55bf339595bf865fec73bda8ac99f283b0810c205442021f29c06eea9aR27

That's exactly the issue (diff not updated because no merge or rebase) - this is the state on master:

ray-packages-feedstock/recipe/meta.yaml

Line 28 in 7bb94d4

number: 1

[h-vetinari]

Thanks again!

[h-vetinari]

Seems ray.metrics_agent has been removed?

Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/ray-packages_1624303001859/test_tmp/run_test.py", line 23, in <module>
    import ray.metrics_agent
ModuleNotFoundError: No module named 'ray.metrics_agent'

[h-vetinari]

I'd be fine with removing that import-test (including comment), but would be nice if someone could confirm the upstream API break (removing an importable subpackage) - WDYT @vnlitvinov?

[gshimansky]

Looking at Ray diff between version 1.2.0 and 1.3.0 it seems like they moved metrics_agent.py into _private package.
https://github.com/ray-project/ray/compare/ray-1.2.0..ray-1.3.0

[vnlitvinov]

I'd be fine with removing that import-test (including comment), but would be nice if someone could confirm the upstream API break (removing an importable subpackage) - WDYT @vnlitvinov?

@richardliaw could you please comment?..

[richardliaw]

@vnlitvinov sorry having a bit of trouble following - are you asking to verify that the metrics agent is changes?

[vnlitvinov]

@richardliaw
We've added the check to import ray.metrics_agent to the package CI to make sure we check the Ray initialization pipeline (ref: #16). Is it correct that the ray.metrics_agent is now moved? How should we check that what we build is in a working state?

[h-vetinari]

How should we check that what we build is in a working state?

This because ray.init() seemed to do different things in our CI than for user installs (cf #16). Note though that this is just a baby step - I'd much rather run the full test suite (#5), but it's not clear to me how that should be called. I've asked on the upstream tracker already - would be very helpful if you could support there @richardliaw.

[vnlitvinov]

While we're waiting for a better solution for testing the packages I've changed the import tests to check for ray._private.metrics_agent to keep packaging efforts rolling.

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!