Set minimum version of NCCL to 2.4.6.1

[jakirkham]

The max_pin of nccl is set to x already in the recipe using this run_exports line. This follows the compatibility guidance we were given in issue ( NVIDIA/nccl#218 ).

Checklist

• Used a 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.

I do have some suggestions for making it better though...

For recipe:

• license_file entry is missing, but is expected.

[jakirkham]

Thoughts @conda-forge/core?

[isuruf]

This must match the pinning x. For example if the pinning was x.x, then this should be 2.4. Since the pinning is x it should be 2. This is so that downstream packages can use newer features introduced in later versions.

[jakirkham]

Our goal here is to ensure we build against the oldest version of nccl we care to have supported by all packages using it for maximum compatibility.

If we wanted to bump this later, we can always do a migrator, which would be explicit and preferable to letting this creep forward implicitly due to when we happened to rebuild downstream dependencies.

[isuruf]

cc @mingwandroid

[jakirkham]

FWIW there are other libraries doing this currently. Please see kealib as one such example, which only requires x.x compatibility, but sets the version used in host to 1.4.10.

[mingwandroid]

Ping @jjhelmus and @msarahan, we have our own recipe of this at the minute, not a fork.

[jakirkham]

Yeah I pointed Jonathan to this work very early on. Here's the feedstock.

ref: https://github.com/conda-forge/nccl-feedstock

[jakirkham]

Friendly nudge @conda-forge/core 😉

[CJ-Wright]

I'm fine with this, although the "pin to minimum version" seems like a potential policy discussion.

[jakirkham]

On the minimum pin point, please see ( #309 (comment) ) (if you haven't already).

[isuruf]

the "pin to minimum version" seems like a potential policy discussion.

I agree that it's a policy discussion. There are advantages and disadvantages.

[jakirkham]

Updated the description to note nccl's compatibility.

[isuruf]

As you can see in conda-forge/staged-recipes#9959 (comment) CuPy uses new features of NCCL if compiled against new versions. This means that we have to update the NCCL version in global pinnings every time there is a NCCL pinning to make sure that CuPy has the latest features of NCCL to work with.

[jakirkham]

Actually it is still not clear (at least not to me) what is going on there. It sounds like the concern is being raised that NCCL might be breaking API/ABI, which means we would need a tighter pin than the package has currently. So let's try to understand what is going on there first before jumping to conclusions. 🙂

[scopatz]

I trust @jakirkham to keep this updated as needed. I think having a very tight pinning to get started is fine.

[isuruf]

FYI, this is not a tight pinning. Pin is x in run_exports.