Do not use cupy-cuda v8, as it contains breaking changes

[tommilligan]

Description

Do not use cupy-cuda v8, as it contains breaking changes. See #5193 for a full description.

Types of change

Bug fix in the install process.

Checklist

• I have submitted the spaCy Contributor Agreement.
• I ran the tests, and all new and existing tests passed. (not done, as no code changes)
• My changes don't require a change to the documentation, or if they do, I've added all required information.

Closes #5193

[svlandeg]

Thanks for the report and the fix! Actually, I think we may just fix this in thinc so we don't have to restrict the dependencies here.

[ines]

@svlandeg I guess spaCy and Thinc should match, though? Not sure what takes precedence if we do spacy[cuda90] and spaCy and Thinc define different version ranges here.

Ultimately, it should probably all refer to Thinc and doing spacy[cuda90] should just pull in thinc[cuda90]. But not sure if that works or if it has unintended side-effects?

[svlandeg]

@svlandeg I guess spaCy and Thinc should match, though?

I'm not suggesting to limit the range in Thinc, I'm suggesting / hoping that the fix in explosion/thinc#330 means we won't have to restrict the range at all. Sorry, should have been more clear!

Also, that only works if there are no other breaking changes from cupy-cuda 8.0.0 onwards, ofcourse. [EDIT: but from their release notes, it doesn't look like it]

[tommilligan]

Agree that it doesn't look like v8 will have other breaking changes in it. Maybe it would still be good to add <9.0.0 though, so this isn't repeated next time?

[svlandeg]

Sure, we could do that

[tommilligan]

Updated to restrict to <9.0.0. Please merge or close as applicable 🙂

[svlandeg]

Could you fill in either of these two options by making it [x]?

[tommilligan]

Updated

[svlandeg]

(FYI - I don't think it's useful to force push your changes to "hide" the old commits. If anything, that makes the discussion on the PR & the reviews kind of difficult to follow ;-))