r-base v3.6.0

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.
Notes and instructions for merging this PR:

1. Please check that the dependencies have not changed.
2. Please merge the PR only after the tests have passed.
3. Feel free to push to the bot's branch to update this PR if needed.
4. The bot will almost always only open one PR per version.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one.

_{This PR was created by the cf-regro-autotick-bot.
The cf-regro-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (conda install -c conda-forge rever) and pip (pip install re-ver) installable.
Finally, feel free to drop us a line if there are any issues!}

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[isuruf]

Are we going to merge this or 3.6.1? If it is this, let me know and I can fix the blas, lapack situation here. (It has to be done in a new version)

[ocefpaf]

Are we going to merge this or 3.6.1?

The bot did not sent a PR to 3.6.1 but I can try it here.

If it is this, let me know and I can fix the blas, lapack situation here. (It has to be done in a new version).

Sure. Let me try 3.6.1 first. I'll ping you when I'm done.

[isuruf]

3.6.1 is not released yet. I was referring to not packaging .0 versions and packaging .1 versions

[bgruening]

@ocefpaf there is no 3.6.1 yet, only in a few months. At some point, we agreed to only build the first point release. This is to not build the entire R stack every 2 month or so ...

[ocefpaf]

3.6.1 is not released yet. I was referring to not packaging .0 versions and packaging .1 versions

Ah. OK!

@ocefpaf there is no 3.6.1 yet, only in a few months. At some point, we agreed to only build the first point release. This is to not build the entire R stack every 2 month or so ...

Sure. We don't have to merge this, but we can also just not issue a migration/updates and wait for 3.6.1. I only revived this b/c we discussed it in today's meeting and it would be nice to have you two there to say things like this.

[bgruening]

I only revived this b/c we discussed it in today's meeting and it would be nice to have you two there to say things like this.

True, sorry.

[ocefpaf]

True, sorry.

No need to be sorry. I know we are all busy, sorry if I made you feel guilty. I only want to re-invite you two to participate and we can re-discuss the meeting times to make it more convenient in that is a problem.

[ocefpaf]

Windows is failing with:

./build.sh: line 265: conda.bat: command not found
mv: cannot stat 'C:/bld/r-base_1557951412767/work/lib/R/Tcl/Library/mingw-w64/*': No such file or directory

Calling conda at build time and move things like that is a terrible hack but I get that r-base is not easy. @mingwandroid do you have a better suggestion for us here?

[dpryan79]

Related to this, do we really need to restrict R packages to point releases? They should be compatible within minor versions these days, or did the R core team indicate at some point that this isn't the case?

[jdblischak]

Related to this, do we really need to restrict R packages to point releases? They should be compatible within minor versions these days, or did the R core team indicate at some point that this isn't the case?

@dpryan79 It's my understanding that this is not possible. See this discussion between @mingwandroid and @isuruf.

[dpryan79]

I'll ask the R folks about patch-level byte-code compatibility. I'd be quite surprised if that didn't work, since users typically update R patch versions without reinstalling packages.

[dpryan79]

It seems the original discussion of compatibility was totally correct. This is from R-core members:

I think R-core tries not to break compatibility with patch-level releases, but 'guarantee' is a strong word. It doesn't help to 'delay' expect until the end of the release series -- breaks are no less likely later in the release cycle than earlier.

And a follow-up:

FWIW we've actually seen non-backward compatibility changes across patch-level R releases in a few occasions in the past so I wouldn't assume that they won't happen again.

So it seems that folks like me who routinely mix packages built with 3.5.1 and 3.5.2 are playing with fire.

[h-vetinari]

R 3.6.1 is scheduled for July 5th: http://developer.r-project.org/

[mingwandroid]

So it seems that folks like me who routinely mix packages built with 3.5.1 and 3.5.2 are playing with fire.

@dpryan79 what about the CRAN binaries for Windows and macOS? They are rebuilt only against x.x

[johanneskoester]

@dpryan79 what about the CRAN binaries for Windows and macOS? They are rebuilt only against x.x

Good catch @mingwandroid, this seems indeed strong evidence for the fact that it might not be an issue in practice. If they would seriously break things, they would break CRAN on win and macOS, right?

[mingwandroid]

Yeah I think we'll be ok, or at least as ok as CRAN is!

[johanneskoester]

That would be a HUGE improvement for both Bioconda, conda-forge and all cutting edge R users! Glad to hear that you agree @mingwandroid!

[mingwandroid]

Please take a peek at the R 3.6.0 build out that was completed recently. We used noarch: generic where possible (about half the time) and pin to x.x now.

[johanneskoester]

@mingwandroid you mean in the default channel?

[mingwandroid]

Default's R yeah.

[johanneskoester]

Wasn't there a strategy to keep them in sync with conda-forge, so that we don't have to redo the work here?

[dpryan79]

@mingwandroid I've always found pinning to x.x.x weird. R itself pins to x.x, so the core team leads everyone to believe that that really should work. Like I expect many people, I've been sharing packages between different patch-level releases for years, so I'm certainly 👍 on this and say we should just deal with the odd broken package when it (rarely) happens.

[mingwandroid]

We're compatible now by virtue of sharing compilers and recipes.

I don't know that we have explicit statements around R though in terms of how we cooperate beyond that.

We have talked informally that AD will always try to get the .0 releases done and conda-forge might skip those waiting for the .1 or .2 but really I don't think we need to be hugely concerned about compat. Things generally will work .. and if they don't we'll deal with it (the usual way, fixing the compat issue or else using channel priorities or ignoring defaults).

To get the new pinning in the recipes we do need to reskeleton them.

[johanneskoester]

@mingwandroid all fine, I just thought that somebody said at some point that defaults recipe sources are meant (or planned) to be based on conda-forge (so, in github speak a fork or a clone or submodules of forks or whatever solution you have designed). In that case, I thought it might be easy for you guys to contribute back any changes. But all this might be just my personal misinterpretation, so no worries.

[johanneskoester]

@ocefpaf when we want to change the pinning now, I guess there needs to be a PR against conda-forge-pinning-feedstock? How do we orchestrate this with the new version of r-base? First the pinning change and immediately afterwards the update of the r-base version, such that the triggered rebuilds do not accidentally use the old x.x.x pinning?

[dpryan79]

@bgruening and I were just discussing the pinning change off-line. Our proposal would be:

1. Merge in R-base 3.6.1, since it was released today.
2. Once that is deploy, make a PR on conda-forge-pinning to simultaneously change the pinning to 3.6 and relax it to any patch level release in that.

[mingwandroid]

@johanneskoester hi, no problem at all! The official position of AD wrt R is that only some packages need patches and careful, cooperative maintenance and I think we're all doing that (though I am the worst at personally pushing my changes back, I'm happy to try to help out where I can on those and will apologise to everyone for having a terrible schedule (I got chemo today quite out of the blue - really! - and I always was bad with estimates)). Anyway it's nice to see the good accumulation of knowledge around R, I've learnt a lot for sure (and yet far too little).

We want to maintain as little as possible in recipe and patch terms, automate as much as possible, mostly down to improving skeleton cran, getting to the stage where the output of that works in nearly every case so carrying recipes becomes the exception. We might want to try to engage with the R foundation on trying to get patches to R merged such that they're good enough and engage in questions around javareconf being moved from core R into RJava instead.

Cheers.

[ocefpaf]

@ocefpaf when we want to change the pinning now, I guess there needs to be a PR against conda-forge-pinning-feedstock?

Yep.

How do we orchestrate this with the new version of r-base? First the pinning change and immediately afterwards the update of the r-base version, such that the triggered rebuilds do not accidentally use the old x.x.x pinning?

Yep. Do you want to change the pinning to x.x?