Overly precise click==8.0.4 pin?

[ryan-williams]

I have a project that uses click==8.1.3 and pip is unhappy due to dask-cuda's click==8.0.4 pin.

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
dask-cuda 22.4.0 requires click==8.0.4, but you have click 8.1.3 which is incompatible.

Are there any known issues with other 8.x versions of click, or might e.g. click>=8.0 suffice?

[pentschev]

I believe click>=8.0 won't suffice, as per the description from #883 .

@charlesbluca do you know if we could make the click dependency less restrictive? Perhaps we may need to skip some versions, like 8.1.0.

[ryan-williams]

Thanks for the pointer. I see #883 chose click==8.0.4 based on rapidsai/integration#453, which in turn points at psf/black#2964, which says:

Please use Black 22.3.0 which was just released to fix this issue or pin Click to 8.0.0, 8.0.1, 8.0.2, 8.0.3, or 8.0.4.

Possible routes forward:

• upgrade to black>=22.3.0 here (and in other Rapids libraries?)
• upgrade to click>8.1.0? (previous comment suggests the issue may be specific to click==8.1.0 & black<23)
• Vendor click
  • Metaflow recently did this Vendor click as dependency for Metaflow Netflix/metaflow#929
  • Maybe more complex than it's worth, but otoh click is a good candidate for vendoring for exactly the reasons we're running into here: many libraries in a given dependency tree are liable to use different versions of click, basically at random and independently from one another

I don't think it's super urgent, just noting what I see as the options. My click==8.1.3 project seems to work fine despite pip complaining about the broken 8.0.4 pin here; I'm not sure we are exercising whichever parts of this library depend on click.

[charlesbluca]

I see #883 (comment) based on rapidsai/integration#453, which in turn points at psf/black#2964,

IIRC, this issue was actually unrelated to the breakage in Black (though we did bump to 22.3.0 in #889), and was because of issues with dask-cuda's CLI caused by the bump to click 8.1.0 (some additional context on this in #883 (comment)), which in turn stemmed from issues with Distributed's CLI.

Assuming that this has been resolved on Distributed's end (and our Dask min version bumped accordingly), we should be safe to go back to the looser pinning we once used prior to #883.

[jakirkham]

Believe this fixed the Distributed issue ( dask/distributed#6018 ). Though it landed in a version of Distributed after the one we pinned to in that RAPIDS release. Should be good to relax click now

[charlesbluca]

Yup, opened #932 to hopefully resolve this