Could someone please reply to https://stat.ethz.ch/pipermail/r-package-devel/2019q1/003473.html
my package in question can only be online next week, but here's a script 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
btw: sf 0.7.2, R 3.4.3, x86_64-w64-mingw32/x64 (64-bit)
I'm not on that list. @brry : I'm afraid that if you want to use that package, you'll have to use it. You can't have the cake and eat it. Either be happy with data.frame's, or use [.sf from the sf package.
@edzer : the problem is that CRAN is not happy about sf:::"[.sf" (with three colons).
Maybe you can consider exporting "[.sf", but I have no idea about the implications, so this is just a thought.
For now, my package will load sf, either with requireNamespace("sf") in my function or by importing a single (random) function #' @importFrom sf st_sf.
With both ways, the subsetting method becomes available.
From my side, this issue can be closed.
It exports the S3 method, not the function. This is the usual, and recommended way.
I think sf is doing it right. It's the packages that want to make use of sf objects that may need changes.
Thanks, Duncan!
Curiously, this is where we were with sp and its (S4) class definitions in relation to rgdal and rgeos. Is it worth considering an sf_lite with the class methods for cases like this, on which sf with the fully fitted bathroom and kitchen would depend? Then packages just needing the class methods could get what they need without triggering static builds bulk installs of GDAL and GEOS? Is the sf codebase sufficiently modular to split out the class methods? Which methods? With sp, we had the additional advantage that objects "knew" which package contained definitions and methods.
You'd have to give up crs validation, for one thing.
Yes, that was sp's pact with the devil too, accept arbitrary user input without checking if rgdal was not available. We never then got to adding a 'validated' attribute to the crs, but maybe should have?
Currently we don't need it, but yes, that would be a way out.
Most helpful comment
I think
sfis doing it right. It's the packages that want to make use ofsfobjects that may need changes.