Failing installations of ggraph 2.2.0 with R versions 3.6 and 4.0

[bockthom]

We have a CI test pipeline in which R package ggraph is installed from CRAN (in its most recent version).
From today on, our pipeline fails to install package ggraph for R versions 3.6. and 4.0 (but succeeds installing it for more recent R versions 4.1, 4.2, 4.3).

As far as I have seen, none of the package updates has changed its requirements regarding the supported R versions. When looking at your repository, I can see that also your own CI pipeline fails for R versions 3.6 and 4.0 and it breaks when compiling package statnet.common version 4.9.0 (here). But statnet.common version 4.9.0 has been released almost one year ago. So, I assume that ggraph imports statnet.common and ggraph version 2.2.0 cannot be installed in R versions 3.6. and 4.0 because of an internal error in ggraph that is somehow related to how ggraph tries to build statnet.common. Am I right with my assumption?

Could you please have a look at this problem and potentially find a solution such that ggraph becomes availabe and installable for R versions 3.6 and 4.0 again?
Thanks in advance!

[thomasp85]

This is probably because CRAN now disallows packages to specify C++11 requirements. This makes packages that require at least C++11 to fail on older builds. Not much we can do about it

[bockthom]

Really? Do you have a reference to that which describes the disallowance of CRAN and when CRAN started to change this?
We install many different R packages from CRAN, and ggraph is the only package that ends up in a build failure while installation, and this only holds from today on. Up until yesterday, everything has been fine with the installation.

[thomasp85]

Sorry, I spoke too soon. This is indeed an error in statnet.common. Why that package is failing I cannot say but you should take it up with the maintainers of that package

ggraph does not "build" statnet.common in any way. It is not a direct dependency and is only required through other dependencies

[thomasp85]

My point about C++11 is still valid but maybe they somehow fixed this on older R versions. It was a big issue a while back

[bockthom]

Do you know about anything regarding that which has changed in your last release of ggraph? Any different dependencies or something else compared to the previous release? If today's release and the preceeding release of ggraph both depend on the same version of statnet.common, the installation must already have failed prior to today's release. However, as the installation failure started to occur with the new release of ggraph, something must have changed regarding the dependencies.

[thomasp85]

Ah, the statnet.common was a red herring... The reason is that ggraph now uses the native pipe which was introduced in 4.1

[bockthom]

Ah, this explains the problem, thanks for investigating this more thoroughly! Would it be possible to replace the native pipe to ensure compatibility with older R versions and provide a fixing release via CRAN?

[thomasp85]

Well, sure I could, but... I also don't think it is reasonable to expect packages to not adapt improvements in new versions of the core language. The old version of ggraph will continue to work in your old systems.

Tidyverse at large has a 4-year support period so at some point in the not so distant future you'll have to give up on building new releases on these old systems anyway (3.6 is already unsupported)

[bockthom]

Well, sure I could, but... I also don't think it is reasonable to expect packages to not adapt improvements in new versions of the core language. The old version of ggraph will continue to work in your old systems.

On the one hand, I agree with you on that regard. On the other hand, unfortunately, R does not provide any option to automatically install the most recent package version that is compatible with the used R version, which lets CI pipelines fail as CRAN will say that the package is not availabe for a given R version although there would be a previous package version that would work. Hard-coding package versions is not an option for me, as one would not get automated updates and bug fixes then, and one would also not recognize bugs in new releases as yours. I would not have recognized this issue if our automated CI pipeline wouldn't have failed on that 😉

Tidyverse at large has a 4-year support period so at some point in the not so distant future you'll have to give up on building new releases on these old systems anyway (3.6 is already unsupported)

According to their dependencies, this is wrong. The current version of tidyverse on CRAN still says it depends on "R (≥ 3.3)".
(But I have not tried it installing, it is not part of the R packages I use.) And even a 4-year support period would not be over yet - R 4.0.5 was released in March 2021, so there would still be one more year of support in a 4-year support period.

So, in the end it is up to you, of course. I would be in favor of backwards compatibility as it would ease automatic package installation, not only but also in CI pipelines (otherwise we must completely stop the CI pipeline for R version 3.6 and 4.0, which would also mean that we would not recognize further dependency violations as this one in other R packages that will potentially occur, which would mean that we would not detect such issues in other projects any more). We install more than 100 widely-used R packages and all of them still support R 3.6 and R 4.0.
If you decide to not support these old versions any more (which I can completely understand, of course), then I still would expect you to upload a new fixing release to CRAN in which you update the "Dependencies" section in the DESCRIPTION file to clearly state that your package depends on "R (≥ 4.1)" (Interestingly, you currently state that you depend on "R (>= 2.10)", so it would be a great leap to update to 4.1...). This is necessary to avoid weird build failures that lead to discussions as this one, since CRAN would not allow to install your package on older R versions then.

[thomasp85]

Yeah, I do agree my lack of updating the R version requirement needs updating so I'll need to make a patch release either way.

As for tidyverse, my point is that we (I'm on the team) only promise 4 years of backward compatibility and we will probably adopt the native pipe in a year when it becomes possible.

[bockthom]

I fully understand that, thanks for the clarification regarding tidyverse.

Anyway, could you give an approximate estimate of when a patch release (either way) will be available?

[malcolmbarrett]

I hadn't realized the recent release switched to the native pipe. I want to argue for reverting this change. I love the native pipe. I use it in personal projects and intend to switch all my packages over in time. However, I think it's too early for a package with as many reverse dependencies as ggraph. This change, for instance, affects ggdag's R dependency, and I think supporting older versions of R is important for that package because of my understanding of the community that uses it. Also, ggraph still depends on magrittr via dplyr, so nothing has changed in the dependency graph except for bumping the R dependency.

It's not the worst bump, so I can make do. But I think it would be better to revert and wait longer. I wasn't planning on switching my packages until more like R 4.5.0 or 4.6.0 because the pipe wasn't fully featured in 4.1.0 (IMO it wasn't until 4.2.0) and in the case of ggdag because I would likely have a dependency on magrittr anyway until dplyr switches (assuming it does).

[thomasp85]

I have just submitted a new version to CRAN removing the use of the native pipe.

It remains failing on some checks due to the first mentioned statnet.common compilation issue. Nothing I can do about that, but it only depends on it indirectly and soft through the suggested network package

[malcolmbarrett]

I appreciate your flexibility on that, thank you

[bockthom]

Thanks a lot, my CI pipeline now works again for all the tested R versions 😄