Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ray 1.4.1 #28

Merged
merged 15 commits into from
Aug 10, 2021
Merged

Ray 1.4.1 #28

merged 15 commits into from
Aug 10, 2021

Conversation

krfricke
Copy link
Contributor

@krfricke krfricke commented Aug 6, 2021

Build passes locally

Closes #20

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.

cc @vnlitvinov

@conda-forge-linter
Copy link

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.

@h-vetinari
Copy link
Member

@conda-forge-admin, please rerender

Copy link
Contributor

@vnlitvinov vnlitvinov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @krfricke for taking this up!
Please update requirements in meta.yaml, and we should be good to go when CI passes.

Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking this up!

The rerender I triggered was so that you actually become a maintainer when this PR is merged. 🙃

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

Thanks for your help reviewing this! Updated the dependencies in the meta.yaml

@h-vetinari
Copy link
Member

Thanks for your help reviewing this! Updated the dependencies in the meta.yaml

Did you see my comments? This is a misspecification (cython is debatable, but numpy certainly). I'd ask you to revert (or rebase out) that commit.

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

There are CI failures that seem to be unrelated:

+ conda install --yes --quiet conda-forge-ci-setup=3 conda-build pip -c conda-forge
Collecting package metadata (current_repodata.json): ...working... 
CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/noarch/current_repodata.json>
Elapsed: -

An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.
'https://conda.anaconda.org/conda-forge/noarch'

can we re-trigger those tests?

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

In this commit: fbb74dc
I updated the meta to reflect the dependencies from the setup.py - I thought that was what you meant, or did I misunderstand?

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

Ah sorry I became confused by the comments. Happy to revert the commit

This reverts commit fbb74dc.
@vnlitvinov
Copy link
Contributor

@h-vetinari do you know what's going on? seems like something very low in the dependency chain had updated glibc (I wonder what it was), but the image used here does not have new enough glibc...

@h-vetinari
Copy link
Member

Can you try adding - sysroot_linux-64 2.17 # [linux64] to the build requirement of the failing package (presumably ray-core)?

@h-vetinari
Copy link
Member

Ah, and we probably will need something like

cdt_name:  # [linux]
  - cos7   # [linux]

in conda_build_config.yaml (needs to be created; then rerendered)

@vnlitvinov
Copy link
Contributor

I am still wary about moving to cos7 as I saw compatibility issues with other packages - is it now the default version in conda-forge?

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

I added sysroot linux - let me know about cos7

@h-vetinari
Copy link
Member

I am still wary about moving to cos7 as I saw compatibility issues with other packages - is it now the default version in conda-forge?

CentOS 6 is EOL since more than half a year. conda-forge is still discussing about migrating (conda-forge/conda-forge.github.io#1436) but most people are ready to do it.

The compatibility issues should be simple (and mostly in conda-forge CI) - you cannot be on cos6 and also depend on a package built against glibc 2.17.

By adding the nodejs-dependency, we won't be able to avoid it here: https://github.com/conda-forge/nodejs-feedstock/blob/master/recipe/meta.yaml#L33

@h-vetinari
Copy link
Member

I added sysroot linux - let me know about cos7

It's probably gonna fail because the default image does not have a new enough glibc to satisfy that constraint.

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

@conda-forge-admin, please rerender

@github-actions
Copy link
Contributor

github-actions bot commented Aug 6, 2021

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you but ran into some issues, please ping conda-forge/core
for further assistance. You can also try re-rendering locally.

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

subspace that is not fully implemented. To be clear:
.. we did not find ['cos7'] from {'cdt_name': ['cos7']} in cdt_name:['cos6', 'cos6']

Not familiar with this config, any pointers? I'll try to look this up in the meantime

@h-vetinari
Copy link
Member

Not familiar with this config, any pointers? I'll try to look this up in the meantime

Sorry, I always forget the details; let me fix it.

@h-vetinari
Copy link
Member

Do you mind if I push into your PR?

@krfricke
Copy link
Contributor Author

krfricke commented Aug 6, 2021

Not at all, please go ahead!

Kai Fricke and others added 2 commits August 6, 2021 22:47
Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linux passes, hopefully windows will too; LGTM (though I realized too late that the build number should ideally still be reset to 0)

Comment on lines -1 to +3
From 3c5886d8d47152735536fc7809908bbbad8041dd Mon Sep 17 00:00:00 2001
From: Vasily Litvinov <vasilij.n.litvinov@intel.com>
Date: Fri, 4 Dec 2020 12:49:34 +0300
From 353efadf23e790e831f87021ae5d4517331e9a2d Mon Sep 17 00:00:00 2001
From: Kai Fricke <kai@anyscale.com>
Date: Fri, 6 Aug 2021 11:36:40 +0100
Copy link
Member

@h-vetinari h-vetinari Aug 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sidenote: we try to keep the attribution to the original authors when rebasing patches; less for the glory and more for knowing who to ask about it ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry! I just git am'd everything and created new patches with git format-patch which seems to have lost the original authors. I'll try to sort this out

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah so this was only in this patch, and because I actually didn't git am it after all (because of conflicts) but manually did the required changes again and committed with the same commit message. What is the best way to go about this next time?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the best way to go about this next time?

For me personally, I keep a branch in a local copy of the upstream repo that I rebase onto new versions, and if a conflict occurs, I try to use git commit -m "<original_message>" --author="<original_author>" --date="<original_date>" after resolving possible conflicts (if none exist, it'll be fine already).

# Conflicts:
#	recipe/conda_build_config.yaml
Copy link
Contributor

@vnlitvinov vnlitvinov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly good, so stamping approval.
Would like to see my questions answered, though.

cuda_compiler_version: # [linux64]
- None # [linux64]
docker_image: # [linux64]
- quay.io/condaforge/linux-anvil-cos7-x86_64 # [linux64]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so there is no way to stay on cos6?

Copy link
Member

@h-vetinari h-vetinari Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we cannot, see this comment, specifically:

By adding the nodejs-dependency, we won't be able to avoid it here: https://github.com/conda-forge/nodejs-feedstock/blob/master/recipe/meta.yaml#L33

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we can use older nodejs, e.g. one from 14.x version part, which is still in "active" phase according to their schedule and works on cos6 :)

Copy link
Member

@h-vetinari h-vetinari Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, this comment didn't show up in the main thread for some reason.

I'm strongly against pinning to old versions for the sake of EOL distros.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you feel so strongly about cos6-support, we can add a branch where nodejs is pinned to 14.x, but master must move on. (though this would need some care with the build numbers; e.g. build numbers on master start from 100)

@@ -71,6 +71,7 @@ outputs:
- {{ compiler('cxx') }}
- bazel <=3.4.1 # [not win]
- bazel <3.7 # [win]
- sysroot_linux-64 2.17 # [linux64]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we update the base to cos7 do we need to manually add this?..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's necessary so that this package gets the correct run-export (so that packages depending on ray fail to build if they don't have cos7 themselves), otherwise we might get crashes with the ABI.

@@ -305,3 +306,4 @@ extra:
- dHannasch
- h-vetinari
- vnlitvinov
- krfricke
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

welcome on board! 🙃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, already mentioned that on the last PR - happy to have you on board!

@krfricke
Copy link
Contributor Author

krfricke commented Aug 9, 2021

FYI I prepared the update for Ray 1.5.0 based on this revision and will open the PR once this has been merged

Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's put this in 🙃

cuda_compiler_version: # [linux64]
- None # [linux64]
docker_image: # [linux64]
- quay.io/condaforge/linux-anvil-cos7-x86_64 # [linux64]
Copy link
Member

@h-vetinari h-vetinari Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we cannot, see this comment, specifically:

By adding the nodejs-dependency, we won't be able to avoid it here: https://github.com/conda-forge/nodejs-feedstock/blob/master/recipe/meta.yaml#L33

@@ -71,6 +71,7 @@ outputs:
- {{ compiler('cxx') }}
- bazel <=3.4.1 # [not win]
- bazel <3.7 # [win]
- sysroot_linux-64 2.17 # [linux64]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's necessary so that this package gets the correct run-export (so that packages depending on ray fail to build if they don't have cos7 themselves), otherwise we might get crashes with the ABI.

@@ -305,3 +306,4 @@ extra:
- dHannasch
- h-vetinari
- vnlitvinov
- krfricke
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, already mentioned that on the last PR - happy to have you on board!

@h-vetinari h-vetinari added the automerge Merge the PR when CI passes label Aug 9, 2021
@vnlitvinov vnlitvinov removed the automerge Merge the PR when CI passes label Aug 9, 2021
@vnlitvinov
Copy link
Contributor

@h-vetinari I've removed "automerge" label because I want to finish the cos6 vs cos7 discussion first.

@h-vetinari
Copy link
Member

@h-vetinari I've removed "automerge" label because I want to finish the cos6 vs cos7 discussion first.

Unless you can remove the nodejs dependency, there is no wiggle room on this.

@h-vetinari
Copy link
Member

I don't understand the problem though - cos6 is EOL for almost a year, glibc 2.12 is a decade old. There's a vanishingly small fraction of users affected by moving to cos7.

The only pain is having to build all packages dependent on ray with cos7 as well, but that's manageable IMO. Also conda-forge will move to cos7 in the foreseeable future (see link above), it just takes a bit longer when it's on such a scale.

@h-vetinari
Copy link
Member

@vnlitvinov
I'd like to merge this and make our way towards 1.5.1. If you want to have a branch for cos6 (pinning old nodejs), we can do that, but should then adapt the build number scheme before merging (the higher ones being reserved for master branch). Obviously, I'd prefer to avoid that hassle and just require cos7, because - as laid out above - I really don't see the issue with doing that.

@vnlitvinov
Copy link
Contributor

Okay, let's be bold and just move to cos7 - on our way to the shiny future! Thanks @krfricke again for your efforts and for taking this up!

@vnlitvinov vnlitvinov merged commit 31dca52 into conda-forge:master Aug 10, 2021
@krfricke krfricke deleted the ray-1.4.1 branch August 10, 2021 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants