[R-pkg-devel] sf subsetting with square bracket
I was pointed to a similar problem in data.table: https://github.com/Rdatatable/data.table/issues/2341 It turns out it is sufficient to import (any random) single function from sf. The "[" method will then be available as well. E.g. with the following line included, the sf methods are available without the package being attached first: #' @importFrom sf st_sf Is this cleaner than requireNamespace("sf") because it only loads a single function? Both approaches work fine. Thanks, Duncan, for digging into this! Btw: sf people are aware: https://github.com/r-spatial/sf/issues/970 Kind regards, Berry
From: Duncan Murdoch <murdoch.duncan at gmail.com>
Sent: Monday, February 4, 2019 15:11
To: Berry Boessenkool; R package devel
Subject: Re: [R-pkg-devel] sf subsetting with square bracket
Sent: Monday, February 4, 2019 15:11
To: Berry Boessenkool; R package devel
Subject: Re: [R-pkg-devel] sf subsetting with square bracket
On 03/02/2019 8:26 p.m., Duncan Murdoch wrote: > On 03/02/2019 5:21 p.m., Berry Boessenkool wrote: >> >> Hi, >> for a MWE: >> https://gist.github.com/brry/7728b9b2d35afad7f1fc5978c3315009 >> The script uses devtools and osmplotr to >> - create a package with a bare minimum dummy function >> - run the code showing the problem >> - create a solution using the ::: import >> - clean up, removing the package and the folder for it > > Thanks. I can confirm the issue. I think the problem is that neither > your sample package nor osmplotr declares a dependency on sf, and it is > not loaded. I don't know if it makes sense for your package to do so, > but osmplotr probably should, since it is creating "sf" objects. > > If I force sf to be loaded by changing your dummy function to > > dummy <- function(map,obj) > { > requireNamespace("sf") > add_osm_objects(map, obj[1:10,], col='green') > } > > then things are fine. In your real package, you'll want to be prepared > to handle the case where "sf" is not installed. > > sf is a big package, so maybe it's intentional to not require it. I > don't know these packages at all, but it seems to me that if osmplotr is > returning objects of class "sf", then it should probably make sure that > the "sf" package is loaded so that methods can be found. I've reported this on the osmplotr Github page: https://github.com/ropensci/osmplotr/issues/46. It appears that osmdata has the same issue, but the maintainers know about it and are working on it. In the meantime I'd add the requireNamespace("sf") call to your package just to be defensive. Duncan Murdoch