[ci] prefer older binary to new source for R packages on Mac builds (fixes #4008)

[jameslamb]

This PR proposes a fix to #4008. The root cause for that issues is that {data.table} recently did a release, but binaries are not available from CRAN yet for it. As a result, the newest version is being compiled from source in CI, and that compilation is failing.

This PR proposes changing the strategy for installing dependencies to "install the newest binary" instead, so that such temporary situations won't disrupt CI and slow development on the entire project in the future.

This reverts the change made in #3876. Since R package builds have to pass for any LightGBM PRs to be merged, I think we should prefer minimizing disruptions even if it means that it takes an extra day or two for our CI to start using the newest version of a dependency.

How I tested this

I tested on my Mac. I could reproduce the original problem and confirm this fixes it.

source install

binary install

References

Based on the advice in https://community.rstudio.com/t/prefer-install-packages-from-binaries-in-windows/50760.

[StrikerRUS]

Thank you.

[jameslamb]

ha we cannot win! Now the linux regular job on Azure failed with an issue related to dependencies

/__w/1/s/.ci/test.sh: line 224: jupyter: command not found

Looks like some issue with version conflicts,coming from

LightGBM/.ci/test.sh

Line 223 in 646267d

conda install -q -y -n $CONDA_ENV ipywidgets notebook

.

Here are the last few lines

notebook -> traitlets[version='>=4.2.1'] -> enum34
attrs -> hypothesis -> enum34
ipywidgets -> traitlets[version='>=4.3.1,<6.0.0'] -> enum34

Package cytoolz conflicts for:
dask -> cytoolz[version='>=0.7.3|>=0.8.2']
distributed -> cytoolz[version='>=0.7.4|>=0.8.2']
dask -> distributed[version='>=2.12.0'] -> cytoolz[version='>=0.7.4']

Package wheel conflicts for:
pip -> wheel
python=3.9 -> pip -> wheel

Package fribidi conflicts for:
graphviz -> pango[version='>=1.42.1,<2.0a0'] -> fribidi[version='>=1.0.2,<2.0a0|>=1.0.5,<2.0a0|>=1.0.9,<2.0a0']
graphviz -> fribidi[version='>=1.0.4,<2.0a0']
pango -> fribidi[version='>=1.0.2,<2.0a0|>=1.0.4,<2.0a0|>=1.0.5,<2.0a0|>=1.0.9,<2.0a0']
python-graphviz -> graphviz -> fribidi[version='>=1.0.4,<2.0a0']

Package scandir conflicts for:
pytest -> pathlib2[version='>=2.2.0'] -> scandir
importlib_metadata -> pathlib2 -> scandir

Package matplotlib-base conflicts for:
matplotlib -> matplotlib-base[version='3.1.2|3.1.2|3.1.2|3.1.3|3.1.3|3.1.3|>=3.2.1,<3.2.2.0a0|>=3.2.2,<3.2.3.0a0|>=3.3.1,<3.3.2.0a0|>=3.3.2,<3.3.3.0a0|>=3.3.4,<3.3.5.0a0',build='py36hef1b27d_1|py38hef1b27d_0|py36hef1b27d_0|py37hef1b27d_0|py38hef1b27d_1|py37hef1b27d_1']
bokeh -> matplotlib -> matplotlib-base[version='3.1.2|3.1.2|3.1.2|3.1.3|3.1.3|3.1.3|>=3.2.1,<3.2.2.0a0|>=3.2.2,<3.2.3.0a0|>=3.3.1,<3.3.2.0a0|>=3.3.2,<3.3.3.0a0|>=3.3.4,<3.3.5.0a0',build='py36hef1b27d_1|py38hef1b27d_0|py36hef1b27d_0|py37hef1b27d_0|py38hef1b27d_1|py37hef1b27d_1']

Package msgpack-python conflicts for:
distributed -> msgpack-python[version='>=0.6.0']
dask -> distributed[version='>=2021.2.0'] -> msgpack-python[version='>=0.6.0']

Package qt conflicts for:
pyqt -> qt[version='5.6.*|5.9.*|>=5.9.7,<5.10.0a0|>=5.9.6,<5.10.0a0|>=5.9.4,<5.10.0a0|>=5.6.3,<5.7.0a0']
matplotlib -> pyqt -> qt[version='5.6.*|5.9.*|>=5.9.7,<5.10.0a0|>=5.9.6,<5.10.0a0|>=5.9.4,<5.10.0a0|>=5.6.3,<5.7.0a0']

Package packaging conflicts for:
bokeh -> packaging[version='>=16.8']
pytest -> packaging
dask -> bokeh[version='>=1.0.0,!=2.0.0'] -> packaging[version='>=16.8']

The full log is too large to copy into this comment, but you can view it at https://dev.azure.com/lightgbm-ci/lightgbm-ci/_build/results?buildId=9297&view=logs&j=c28dceab-947a-5848-c21f-eef3695e5f11.

@StrikerRUS if you're available, could you re-run the failed jobs for this PR on Azure? Since you have permissions (#3819 (comment)) and I don't right now (#3819 (comment)). Sorry to bother you with it :/

[StrikerRUS]

Done!
Ahaha, it's getting funny actually!

What CI job will fail next?..

[jameslamb]

that worked, thanks!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.