Installation of `sf` R package fails about geospatial HOT 9 CLOSED

Works for me (tested today):

$ docker run -it rocker/geospatial R

R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library("sf")
Linking to GEOS 3.5.1, GDAL 2.1.3, proj.4 4.8.0
> sessionInfo()
R version 3.4.0 (2017-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblasp-r0.2.12.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=C
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] sf_0.4-2

loaded via a namespace (and not attached):
[1] compiler_3.4.0 magrittr_1.5   tools_3.4.0    DBI_0.6-1      units_0.4-4
[6] Rcpp_0.12.10   udunits2_0.13  grid_3.4.0

from geospatial.

Yes, this is a version thing with GEOS (working for GEOS > 3.5.0 only), addressed here fixed on GH; will submit to CRAN in a few days.

from geospatial.

@edzer cool, thanks! Looks like things build fine if we install GEOS 3.5.1 from source (https://github.com/rocker-org/geospatial/blob/master/Dockerfile#L39); though sounds like that won't be necessary after your next release. Just wondering if there's good reason to provide the newer GEOS version (could go for 3.6.1) or if in general we're fine sticking with the v3.3 from the debian repos?

from geospatial.

(Complete aside: If you two gentlemen ever have too much funding, set up a workshop and I can do a walk-through on how to solve that with proper [local] .deb packages. It is the missing link you have here, and addressable easily enough. Of course, working from source works too -- but we do like versioned packages on input too.)

from geospatial.

@eddelbuettel thanks, that would be awesome. One difficulty I've had when pulling in more recent .deb binaries for these development libraries on the Jessie images (e.g. via apt-pinning) is that those binaries have been usually been built with newer versions of the compilers than what is already installed on the container. This means that R packages can hit errors compiling against those dev libraries if we don't also update the whole compiler stack, which balloons the image size (and at which point one may as well just start with debian:testing -- which is of course what you've suggested from the beginning; though it that involves different challenges)

from geospatial.

It's sort-of more acute with Ubuntu if and when you upgrade every six months as I do -- but then the (free) PPA service can build for all those version. It is pretty fabulous and I use that for all my Travis needs when I need newer, or otherwise unpackaged, binaries.

Docker is a little different and "should" be simpler -- you may just need one repo to supply, say, newer binaries as here with geos. One could easily construct something like my drat (for R) by using GitHub and its super-reliable web serving to provide add-on .deb repos for use by Debian (and then, say, in Docker).

Ah, another project and another paper to write ... One day, maybe.

from geospatial.

@cboettig GEOS 3.3.0 is sufficient; CRAN is also a wild mix of versions >= 3.3.0. For most practical work, I use the ubuntugis or ubuntugis-unstable ppa.

from geospatial.

This issue should be solved by sf 0.4-1 on CRAN, and #3

from geospatial.

Thanks, looking okay on my end as well, closing this out

from geospatial.