Conversation
|
@jakirkham is there anyway this could be handled on the conda-forge side? Like maybe the pip version should be pinned on python, and the setuptools version can be pinned on that? Probably not that, but something like that? |
|
This unsticks us for now, so I'm going to go ahead and merge. |
Fixes the tests that are failing on import since setuptools was just released and it now warns for when you use `LooseVersion`. We've already made the shift in dask, but some of our environments test older versions of pandas, numpy, and distributed which didn't have the change yet.
|
@jsignell Hi Julia. In conda-forge/conda-forge.github.io#1575 (comment) you mentioned that It would seem that the deprecation warning in question was introduced as early as 59.6.0. Any idea why it wasn't until 60.0.3 that Dask's CI started to fail? Context: my colleagues and I have been investigating an issue where conda fails to create an environment based off a "frozen" environment file (i.e., one generated by |
|
That had not occurred to me as a situation @zzhengnan thanks for taking the time to comment here. I had no idea about conda hotfixes either until this issue came up. I'm not sure why 59.6.0 is fine and > 60 isn't. I didn't dig through the commit history, but I assume that something changed about how or when setuptools raises the warning. |
All the tests are failing this morning since setuptools was just released and it now warns for when you use
LooseVersion. We've already made the shift in dask, but some of our environments test older versions of pandas and numpy which didn't have the change yet. So this puts a ceiling on setuptools in those envs.