Closed MatthieuStigler closed 1 year ago
@MatthieuStigler Can we start at the top please: Which of the two containers did you use?
First off, builds are incremental: if a package is updated, we get the version of that package as it is then. We do not control library versions.
Second, builds are somewhat "unpredictable" in the sense that most package rely on the underlying RSPM/PPM binary. But just to make everybody's life a bit more, maybe 2% or 3% packages comes as source because RSPM/PPM in their magic does not / cannot build it. At that point I build it from source. But it is bloody hard to align it with RSPM/PPM builds I have no control over.
(Third, BioConductor is always from source.)
So in short if something fails let me know and I can maybe rebuild. If it merely warns that is maybe not worth the effort. Overall maybe we need a 'census' for some packages to ensure they all have consistent library versions. Maybe the geospatial community has such a script.
Mmh, not sure what are the containers, I am using it here without a Docker infrastructure, just on my machine (using https://dirk.eddelbuettel.com/cranapt
). So I guess yes it is difficult to make the example fully reproducible?
Regarding the gravity of the problem, it is hard to tell, so far I encountered quite a few warnings due to the versions mismatch. Given how central sf
is to my workflow and how often the warnings appeared, I felt I wanted to make sure they would not appear again.
I don't have any understanding of the RSPM/PPM, but is it possible that sf requires re-compilation whenever rgeos/rgdal are updated, even if sf itself is not updated?
Thanks!!
So substitute 'container flavour' for 'Ubuntu flavour': You haven't told me if the 'issue' arose under focal or jammy.
got you, sorry about that: this is on focal 20.04
That was the first. Jammy may be smoother so I would try that.
Overall, and as you describe above, "it's tricky". So at this stage the best we can probably do is catalog it. And/or add some helper scripts to catalogue versions. We can of course query apt
too. Do you want to poke around a little?
Fair point, I should update at some point.
Mmh, if this is tricky for you, it will be even more for me. I am afraid that besides reporting it, I can't be of much help since I don't know about ppm nor cataloguing :-( I hope at least this post can be useful for later discoverability, if other users encounter the same issue and want to get rid of the warning running bspm::disable(); install.packages(c("sf"))
.
Pretty straightforward: RSPM/PPM is where we get (most) pre-compiled (non .deb) packages from, this is documented. We then turn those into r-cran-* with full dependencies depending on what was compiled into them. So to some extend what "they do here" matters which is why I pointed you here.
Cataloguing: That was just shorthand for available.packages()
and installed.packages()
and friens.
And yes, a local install can always be your local fix. I think I close this now as there is no imminent issue for r2u.
sounds good, thanks for your insights!
Keep me posted if/when you see 'odd' error or warning messages. I think sometimes these may be normal / expected, sometimes they may hint at something. I do build BioConductor in bulk because of their release schedule. Maybe if a few geospatial r2u users stick their heads together we can come up with a 'schema' to do something better (if and when we think it;s needed).
Just for further info, a quick example where non-updated sf might actually lead to an error. Note that I have sudo apt update
with no pending updates (though update.packages()
shows further available packages).
library(sf)
#> Linking to GEOS 3.10.2, GDAL 3.0.4, PROJ 6.3.1; sf_use_s2() is TRUE
#> WARNING: different compile-time and runtime versions for GEOS found:
#> Linked against: 3.10.2-CAPI-1.16.0 compiled against: 3.8.0-CAPI-1.13.1
#> It is probably a good idea to reinstall sf, and maybe rgeos and rgdal too
dang::shadowedPackages()
#> Package LibPath
#> 1: bspm /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 2: bspm /usr/local/lib/R/site-library
#> 3: dang /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 4: dang /usr/lib/R/site-library
#> 5: effects /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 6: effects /usr/lib/R/site-library
#> 7: maps /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 8: maps /usr/lib/R/site-library
#> 9: pryr /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 10: pryr /usr/lib/R/site-library
#> Version n good
#> 1: <package_version[1]> 2 TRUE
#> 2: <package_version[1]> 2 FALSE
#> 3: <package_version[1]> 2 TRUE
#> 4: <package_version[1]> 2 FALSE
#> 5: <package_version[1]> 2 TRUE
#> 6: <package_version[1]> 2 FALSE
#> 7: <package_version[1]> 2 TRUE
#> 8: <package_version[1]> 2 TRUE
#> 9: <package_version[1]> 2 TRUE
#> 10: <package_version[1]> 2 TRUE
st_crs("ESRI:102033")
#> Warning in CPL_crs_from_input(x): GDAL Error 1: PROJ:
#> proj_create_from_database: SQLite error on SELECT name,
#> coordinate_system_auth_name, coordinate_system_code, geodetic_crs_auth_name,
#> geodetic_crs_code, conversion_auth_name, conversion_code,
#> area_of_use_auth_name, area_of_use_code, text_definition, deprecated FROM
#> projected_crs WHERE auth_name = ? AND code = ?: no such column:
#> area_of_use_auth_name
#> Error in st_crs.character("ESRI:102033"): invalid crs: ESRI:102033
Created on 2023-02-24 with reprex v2.0.2
bspm::disable()
install.packages(c("sf", "rgeos"))
#> Installing packages into '/home/mstigler/R/x86_64-pc-linux-gnu-library/4.2'
#> (as 'lib' is unspecified)
library(sf)
#> Linking to GEOS 3.10.2, GDAL 3.4.3, PROJ 8.2.0; sf_use_s2() is TRUE
dang::shadowedPackages()
#> Package LibPath
#> 1: bspm /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 2: bspm /usr/local/lib/R/site-library
#> 3: dang /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 4: dang /usr/lib/R/site-library
#> 5: effects /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 6: effects /usr/lib/R/site-library
#> 7: maps /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 8: maps /usr/lib/R/site-library
#> 9: pryr /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 10: pryr /usr/lib/R/site-library
#> 11: rgeos /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 12: rgeos /usr/lib/R/site-library
#> 13: sf /home/mstigler/R/x86_64-pc-linux-gnu-library/4.2
#> 14: sf /usr/lib/R/site-library
#> Version n good
#> 1: <package_version[1]> 2 TRUE
#> 2: <package_version[1]> 2 FALSE
#> 3: <package_version[1]> 2 TRUE
#> 4: <package_version[1]> 2 FALSE
#> 5: <package_version[1]> 2 TRUE
#> 6: <package_version[1]> 2 FALSE
#> 7: <package_version[1]> 2 TRUE
#> 8: <package_version[1]> 2 TRUE
#> 9: <package_version[1]> 2 TRUE
#> 10: <package_version[1]> 2 TRUE
#> 11: <package_version[1]> 2 TRUE
#> 12: <package_version[1]> 2 TRUE
#> 13: <package_version[1]> 2 TRUE
#> 14: <package_version[1]> 2 TRUE
st_crs("ESRI:102033")
#> Coordinate Reference System:
#> User input: ESRI:102033
#> wkt:
#> PROJCRS["South_America_Albers_Equal_Area_Conic",
#> BASEGEOGCRS["SAD69",
#> DATUM["South American Datum 1969",
#> ELLIPSOID["GRS 1967 Modified",6378160,298.25,
#> LENGTHUNIT["metre",1]]],
#> PRIMEM["Greenwich",0,
#> ANGLEUNIT["Degree",0.0174532925199433]]],
#> CONVERSION["South_America_Albers_Equal_Area_Conic",
#> METHOD["Albers Equal Area",
#> ID["EPSG",9822]],
#> PARAMETER["Latitude of false origin",-32,
#> ANGLEUNIT["Degree",0.0174532925199433],
#> ID["EPSG",8821]],
#> PARAMETER["Longitude of false origin",-60,
#> ANGLEUNIT["Degree",0.0174532925199433],
#> ID["EPSG",8822]],
#> PARAMETER["Latitude of 1st standard parallel",-5,
#> ANGLEUNIT["Degree",0.0174532925199433],
#> ID["EPSG",8823]],
#> PARAMETER["Latitude of 2nd standard parallel",-42,
#> ANGLEUNIT["Degree",0.0174532925199433],
#> ID["EPSG",8824]],
#> PARAMETER["Easting at false origin",0,
#> LENGTHUNIT["metre",1],
#> ID["EPSG",8826]],
#> PARAMETER["Northing at false origin",0,
#> LENGTHUNIT["metre",1],
#> ID["EPSG",8827]]],
#> CS[Cartesian,2],
#> AXIS["(E)",east,
#> ORDER[1],
#> LENGTHUNIT["metre",1]],
#> AXIS["(N)",north,
#> ORDER[2],
#> LENGTHUNIT["metre",1]],
#> USAGE[
#> SCOPE["Not known."],
#> AREA["South America"],
#> BBOX[-60,-90,15,-30]],
#> ID["ESRI",102033]]
Created on 2023-02-24 with reprex v2.0.2
I just did
$ docker run --rm -ti eddelbuettel/r2u:jammy
# install.r sf rgeos
.... omitting output here ...
root@409741feb9cb:/# R -q
> library(sf)
Linking to GEOS 3.10.2, GDAL 3.4.1, PROJ 8.2.1; sf_use_s2() is TRUE
> library(rgeos)
Loading required package: sp
rgeos version: 0.6-1, (SVN revision 692)
GEOS runtime version: 3.10.2-CAPI-1.16.0
Please note that rgeos will be retired during 2023,
plan transition to sf functions using GEOS at your earliest convenience.
GEOS using OverlayNG
Linking to sp version: 1.5-1
Polygon checking: TRUE
>
So in short I do not see a problem. Am I missing something?
oh sorry, I am not familiar with docker
, I will make sure to use that when reporting further issues.
It's just a simple way to "start from scratch" on a clean slate to check the versions in the repo as opposed to whatever I may have hanging around. And it is fast. Has many things going for it.
You also have a old version of the dang
function because it does not print the version numbers right in your example above. A while back I injected an explicit format()
to ensure it does.
Hi Dirk
I get some warnings with the r2u version of
sf
, with the infamous message: WARNING: different compile-time and runtime versions for GEOS found:, which triggered some unusual warnings withst_read
(example code taken from help page ofst_read
).Solution I found was to install myself
sf
from CRAN, disabling bspm:bspm::disable(); install.packages(c("sf"))
. I guess that would be a rather tricky issue to address at the r2u level?Thanks!
output with r2u
sf
Created on 2023-02-19 with reprex v2.0.2
output with CRAN
sf
Created on 2023-02-19 with reprex v2.0.2