r-stringi and r-stringr R 3.5 win64 packages being pulled from defaults instead of conda-forge

[cbrueffer]

In several R recipes that specify r-stringi and r-stringr as dependencies, in the Windows R3.5 build those packages are being pulled from defaults instead of conda-forge, leading to build errors. For R 3.4 build they are pulled from conda-forge as they should.

Examples:

https://ci.appveyor.com/project/conda-forge/r-recipes-feedstock/build/1.0.7/job/8jyn8ky5eef97vlf
https://ci.appveyor.com/project/conda-forge/r-reprex-feedstock/build/1.0.2/job/ikd87p47gemnvko1

CC @bgruening @jdblischak

[jdblischak]

@cbrueffer Two ideas on potential causes:

1. icu hasn't been able to updated recently because it is failing on Windows: Rebuild for Python 3.7, GCC 7, R 3.5.1, openBLAS 0.3.2 icu-feedstock#20 (comment)
2. The conda-forge recipe for r-stringi lists - icu, but the AnacondaRecipes recipe lists - {{native}}icu # [not win]. In other words, the AnacondaRecipes version completely skips the icu dependency (the {{native}} variable never gets used since it is only relevant for [win]).

[jdblischak]

I did a little more investigation. The AnacondaRecipes recipe for r-stringi is able to skip icu completely on Windows because it is installed by their recipe of r-base:

https://github.com/AnacondaRecipes/r-base-feedstock/blob/3b26b363cf050286bf6700347e181a192ce6105a/recipe/meta.yaml#L109

However the conda-forge recipe for r-base only installs icu on non-Windows:

https://github.com/conda-forge/r-base-feedstock/blob/2a9819ff2c06910bf11f6fa1dd1cb9afad264f98/recipe/meta.yaml#L81

Thus I see two options to fix this on conda-forge:

1. Update the r-stringi recipe to install - {{native}}icu on all systems
2. Update the r-base recipe to install - {{native}}icu on all systems

Do we have any reasons to prefer one solution over the other?

[cbrueffer]

Thanks for the investigation @jdblischak! In principle it makes most sense to me to move the dependency to r-stringi, however given that we already have it in r-base in the majority of systems, and the Anaconda recipe does the same, maybe it's easier to just add it to r-base.

[cbrueffer]

Any more opinions on this? Otherwise I'll create a PR to add the icu dependency for win64 to r-base to match the other archs.

[bgruening]

Option 1) from John for now and option 2) for later/next r-base update? I don't see any reason to not have iuc for Windows by default.

[jdblischak]

Waiting on the AppVeyor builds to complete before closing this issue: https://ci.appveyor.com/project/conda-forge/r-stringi-feedstock/build/1.0.29

[jdblischak]

The R 3.5.1 build failed in the link above due to an HTTP timeout error. However, someone restarted a new build which passed.

So I went ahead and restarted the failed recipes build (someone already restarted the failed reprex build).

[cbrueffer]

Thanks @jdblischak, I restarted the other builds but had forgotten about r-recipes.

[jdblischak]

@cbrueffer Can this Issue be closed now?

[cbrueffer]

Yes, everything works fine after the fix to r-stringi. Thanks!

[jdblischak]

@cbrueffer For future reference, the conda-forge recipe for r-base now installs {{native}}icu on Windows. Implemented in PR conda-forge/r-base-feedstock#61

[cbrueffer]

@jdblischak good to know, thanks!