retain attributes

[bart1]

I noticed sf frequently drops attributes when using dplyr, this contrasts to dplyr "normal behavior". I would generally say retaining attributes is desirable both for users that want to retain extra information and for package building on sf. These changes improve this and retain the attributes. Let me know what you think, I can add tests if desirable. The current tests don't show any failures.

This is the current behaviour:

require(sf)
#> Loading required package: sf
#> Linking to GEOS 3.14.1, GDAL 3.12.2, PROJ 9.7.1; sf_use_s2() is TRUE
require(dplyr)
pt1 <- st_point(c(0, 1))
pt2 <- st_point(c(1, 1))
sfc <- st_sfc(pt1, pt2)
d <- st_sf(data.frame(a = 1:2, geom = sfc))
attr(d, "test") <- 1
d |> attr("test")
#> [1] 1
d |> group_by(a) |> attr("test")
#> [1] 1
d |> mutate(aa = a) |> attr("test")
#> [1] 1
d |> rowwise() |> attr("test")
#> [1] 1
d |> distinct(1) |> attr("test")
#> [1] 1

# in all these cases the attribute is removed
d |> arrange(a) |> attr("test")
#> NULL
d |> group_by(a) |> ungroup() |> attr("test")
#> NULL
d |> slice(1) |> attr("test")
#> NULL
d |> sample_n(1) |> attr("test")
#> NULL
d |> select(a) |> attr("test")
#> NULL
d |> rename(b=a) |> attr("test")
#> NULL
sessioninfo::package_info(pkgs = 'sf')
#>  package    * version date (UTC) lib source
#>  class        7.3-24  2026-08-03 [4] CRAN (R 4.6.1)
#>  classInt     0.4-11  2025-01-08 [1] CRAN (R 4.6.1)
#>  DBI          1.3.0   2026-02-25 [1] CRAN (R 4.6.1)
#>  e1071        1.7-17  2025-12-18 [1] CRAN (R 4.6.1)
#>  KernSmooth   2.23-27 2026-08-12 [4] CRAN (R 4.6.1)
#>  proxy        0.4-29  2025-12-29 [1] CRAN (R 4.6.1)
#>  Rcpp         1.1.2   2026-07-05 [1] CRAN (R 4.6.1)
#>  s2           1.1.11  2026-06-01 [1] CRAN (R 4.6.1)
#>  sf         * 1.1-2   2026-07-23 [1] CRAN (R 4.6.1)
#>  units        1.0-1   2026-03-11 [1] CRAN (R 4.6.1)
#>  wk           0.9.5   2025-12-18 [1] CRAN (R 4.6.1)
#> 
#>  [1] /home/bart/R/x86_64-pc-linux-gnu-library/4.6
#>  [2] /usr/local/lib/R/site-library
#>  [3] /usr/lib/R/site-library
#>  [4] /usr/lib/R/library
#>  * ── Packages attached to the search path.

This contrasts to the default behaviour of dplyr where attributes are retained (except for ungroup):

require(dplyr)
d <- (data.frame(a = 1:2, geom = 1:2))
attr(d, "test") <- 1
d |> attr("test")
#> [1] 1
d |> group_by(a) |> attr("test")
#> [1] 1
d |> mutate(aa = a) |> attr("test")
#> [1] 1
d |> rowwise() |> attr("test")
#> [1] 1
d |> distinct(1) |> attr("test")
#> [1] 1
d |> arrange(a) |> attr("test")
#> [1] 1
d |> slice(1) |> attr("test")
#> [1] 1
d |> sample_n(1) |> attr("test")
#> [1] 1
d |> select(a) |> attr("test")
#> [1] 1
d |> rename(b=a) |> attr("test")
#> [1] 1

d |> group_by(a) |> ungroup() |> attr("test")
#> NULL

With this pull request the behaviour of sf is similar to dplyr here is the test case from above with the pull request:

require(sf)
#> Loading required package: sf
#> Linking to GEOS 3.14.1, GDAL 3.12.2, PROJ 9.7.1; sf_use_s2() is TRUE
require(dplyr)
#> Loading required package: dplyr
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
pt1 <- st_point(c(0, 1))
pt2 <- st_point(c(1, 1))
sfc <- st_sfc(pt1, pt2)
d <- st_sf(data.frame(a = 1:2, geom = sfc))
attr(d, "test") <- 1
d |> attr("test")
#> [1] 1
d |> group_by(a) |> attr("test")
#> [1] 1
d |> mutate(aa = a) |> attr("test")
#> [1] 1
d |> rowwise() |> attr("test")
#> [1] 1
d |> distinct(1) |> attr("test")
#> [1] 1

# in all these cases the attribute is removed
d |> arrange(a) |> attr("test")
#> [1] 1
d |> group_by(a) |> ungroup() |> attr("test")
#> NULL
d |> slice(1) |> attr("test")
#> [1] 1
d |> sample_n(1) |> attr("test")
#> [1] 1
d |> select(a) |> attr("test")
#> [1] 1
d |> rename(b=a) |> attr("test")
#> [1] 1
sessioninfo::package_info(pkgs = 'sf')
#>  package * version date (UTC) lib source
#>  DBI       1.3.0   2026-02-25 [1] CRAN (R 4.6.1)
#>  Rcpp      1.1.2   2026-07-05 [1] CRAN (R 4.6.1)
#>  s2        1.1.11  2026-06-01 [1] CRAN (R 4.6.1)
#>  sf      * 1.1-3   2026-08-25 [1] local
#>  units     1.0-1   2026-03-11 [1] CRAN (R 4.6.1)
#>  wk        0.9.5   2025-12-18 [1] CRAN (R 4.6.1)
#> 
#>  [1] /home/bart/R/x86_64-pc-linux-gnu-library/4.6
#>  [2] /usr/local/lib/R/site-library
#>  [3] /usr/lib/R/site-library
#>  [4] /usr/lib/R/library
#>  * ── Packages attached to the search path.

[edzer]

@bart1 that sounds reasonable; would you be willing to carry out a complete CRAN reverse dependency check on this change, and, if any, handle downstream consequences?

[bart1]

@bart1 that sounds reasonable; would you be willing to carry out a complete CRAN reverse dependency check on this change, and, if any, handle downstream consequences?

I just started running revdepcheck I see this takes several days. Assuming you don't have a faster way I will see how many error pop up. Up to now (the first dozen packages), it seems fine.

[bart1]

I now ran a bunch of tests, besides the NAMESPACE issue I have not noticed regressions in other package. There are however quite a few package that fail to test with revdepcheck, do you have any experiences how to prevent these kind of issues, I already tried a timeout of 1800 seconds:

Platform

field	value
version	R version 4.6.1 (2026-06-24)
os	Ubuntu 26.04.1 LTS
system	x86_64, linux-gnu
ui	X11
language	(EN)
collate	en_US.UTF-8
ctype	en_US.UTF-8
tz	Europe/Amsterdam
date	2026-09-09
pandoc	3.7.0.2 @ /usr/bin/pandoc
quarto	NA

Dependencies

package	old	new	Δ
sf	1.1-2	1.1-3	*
classInt	0.4-11	NA	*
DBI	1.3.0	1.3.0
e1071	1.7-17	NA	*
proxy	0.4-29	NA	*
Rcpp	1.1.2	1.1.2
s2	1.1.12	1.1.12
units	1.0-1	1.0-1
wk	0.9.5	0.9.5

Revdeps

Failed to check (144)

package	version	error	warning	note
actel	?
adehabitatHR	?
adw	?
AMISforInfectiousDiseases	?
apsimx	?
arcgisutils	0.6.0	1
atakrig	?
ausplotsR	?
awdb	0.1.4	1
bamlss	?
bayesTFR	?
blisa	?
BOLDconnectR	?
camtrapR	?
cartogramR	?
cartography	?
CDSE	?
cisp	?
CompositionalSR	?
CopernicusDEM	?
d3po	?
dartR.spatial	?
datazoom.amazonia	?
DeclareDesign	?
Directional	?
distanceto	?
DRquality	?
dwp	?
ecochange	?
eks	?
emstreeR	?
enmSdmX	?
epiR	?
espadon	?
fasterRaster	?
fractalforest	?
fsr	?
gbm.auto	?
GDAtools	?
geocausal	?
geocomplexity	?
GeoFIS	1.1.1	1
GEOmap	?
GGoutlieR	?
GISINTEGRATION	?
gmwmx2	?
GREENeR	?
Guerry	?
GWlasso	?
GWmodel	?
GWSDAT	?
HDSpatialScan	?
hemispheR	?
hero	?
HSAUR3	?
ie2miscdata	?
infocausality	?
infoxtr	?
INLAspacetime	?
intamap	?
intamapInteractive	?
knfi	?
landsat	?
lgcp	?
linkeR	0.1.3	1
localsp	?
mapStats	?
MetaNet	?
meteo	?
MIAmaxent	?
mlr	?
ModelMap	?
movegroup	?
mrddGlobal	?
MRG	?
multiflexscan	?
multiscape	?
neuroimaGene	?
OSTA	?
pacu	?
palettephines	?
pargasite	?
patternize	?
pc	?
planisphere	?
PopGenReport	?
protolite	2.4.0	1
psgp	?
pspatreg	?
R2BayesX	?
rasterbc	?
rasterDT	?
RchivalTag	?
recluster	?
recogito	?
recolorize	?
redist	?
ref.ICAR	?
rerddapXtracto	?
RGENERATEPREC	?
rgeoda	?
rgplates	?
rivnet	?
roroph	?
RRgeo	?
rsocialwatcher	?
rtop	?
SegEnvIneq	?
sftime	?
siland	?
SimSurvey	?
soilassessment	?
soilKey	0.9.184	1
sorvi	?
spacetime	?
SpaceTimeBSS	?
SPARTAAS	?
SpatialBSS	?
spatialEco	?
spatialreg	?
spdep	?
spdgp	?
spmoran	?
spsur	?
sshicm	?
stgam	1.2.1	1
stppSim	?
streamDAG	?
surveillance	?
SWTools	?
tabs	?
taxify	0.4.0	1
TeachingDemos	?
terra	?
tmap.sources	?
tmapverse	?
trackeRapp	?
ulex	?
ursa	?
USA.state.boundaries	?
WaterBalanceR	?
weed	?
wflo	?
wxgenR	?