Repository navigation
Deprecated ggplot2 arguments #408
Description
Currently, there are 3 deprecated ggplot2 arguments that appears when running devtools::test():
- The
draw_quantilesargument ofgeom_violin()is deprecated as of ggplot2 4.0.0.
i Please use thequantiles.linetypeargument instead. (Note this deprecation is supposed to sayquantile.linetype, as seen in the documentation https://ggplot2.tidyverse.org/reference/geom_violin.html)
This is only used internally, since the public API for ppc_violin_grouped() uses probs. However, when changing all instances of draw_quantiles to quantile.linetype, a test in test-ppc-distributions.R at line 334/335 fails:
> ppc_violin_grouped(vdiff_y, vdiff_yrep, vdiff_group)
Error:
! Problem while converting geom to grob.
ℹ Error occurred in the 1st layer.
Caused by error in `draw_panel()`:
! `geom_path()` can't have varying colour, linewidth, and/or alpha along the line when linetype isn't solid.
Run `rlang::last_trace()` to see where the error occurred.
ppc_intervals()/ppd_intervals()use deprecated ggplot2 arguments (fatten,size).
The fatten argument of geom_pointrange() is deprecated as of ggplot2 4.0.0.
i Please use the size aesthetic instead.
Using size aesthetic for lines was deprecated in ggplot2 3.4.0.
i Please use linewidth instead.
Changing the public API would be breaking. Furthermore, replacing fatten with size would mean the new size would semantically correspond to the old fatten, not the existing size.
Activity
jgabry commentedon Dec 30, 2025
Thanks @BjarkeHautop! @VisruthSK and I had noticed some of these recently with the release of ggplot2 v4.0. But you mention some additional details I hadn't considered (thank you). A few comments and questions:
Interesting, when I try it I don't see that test failure. There's also
mcmc_violin, but changing it there seems to work too. I just put my version of the violin fixes in #410. Would you be willing to take a look and see if there's a difference between my version and your version that might explain the error? I might have made a mistake somewhere. (We'll also see if the error happens with my PR, it didn't locally, but perhaps it will on Github Actions)I fixed a lot of these uses of
size(in fact I just fixed a couple in the intervals plots), but there are probably some that I missed. Since bayesplot requires at least v3.4.0 of ggplot2 we can safely changesizetolinewidthinternally, we just need to find the remaining cases. Like you said, changing the API would be breaking, so for now we'll keepsizein the user-facing functions and just change it internally. E.g.,mcmc_trace()takes argumentsizebut internally that's passed as thelinewidthargument to ggplot2.Yeah, you're right and this issue with replacing fatten hadn't occurred to me yet. I'm not sure how we should handle it. We might be forced to make a breaking change in bayesplot and remove the
fattenargument and change the behavior ofsizelike you mentioned. Or do you (or anyone else) have any other ideas?Thanks again for opening the issue!
VisruthSK commentedon Dec 30, 2025
I'm in favor of deprecating with a warning to swap then doing a breaking change, I think cli or something has a deprecation badge which handles the messaging.
Edit: https://lifecycle.r-lib.org/reference/deprecated.html is the function/package I was thinking about.
BjarkeHautop commentedon Dec 31, 2025
Pr #410 works for me too, looks good.
Not sure what the best approach is. We have a few options:
Breaking change, changing the meaning of the arguments so that they match ggplot2 syntax.
Deprecate them and change public args to a new name(s), so it doesn't clash with ggplot2 syntax.
Something else?
This isn't possible @VisruthSK. The issue is that the meaning of the arguments would change but keep the same name (as explained above), so you can't just deprecate them.
BjarkeHautop commentedon Dec 31, 2025
Whoops clicked close by accident.
jgabry commentedon Dec 31, 2025
Yeah, I agree this isn't possible in this case unfortunately. Normally we would deprecate and then eventually make the breaking change like @VisruthSK suggested, but because the meaning of the arguments is changing (and the fact that they interact with each other) I don't see how we could do that here.
I guess the second is closest to what @VisruthSK was recommending, but I'm not sure which new names would make sense.
I think the best option might be just to make the breaking change, especially since it would match ggplot2.
For example, for
ppc_intervals()we have defaultssize=1,fatten=2.5. In older versions of ggplot2 the point size ingeom_pointrange()would besize * fattenand in the new version I think it's justsize, right? So what we could do is change the default tosize=2.5and throw a deprecation warning if the user specifiesfatten(e.g. usingfatten = deprecated()like at the link @VisruthSK shared above). Then we can eventually removefatten, but we wouldn't remove it for a while so we don't cause any errors.What do you both think of that idea?
BjarkeHautop commentedon Jan 2, 2026
I agree.
Yes, point size is only controlled through
sizein ggplot2 4.0.0+.Sounds good to me.
jgabry commentedon Jan 8, 2026
Progress update:
size(changed tolinewidth) in Fix allsizewarnings calls to ggplot2 (deprecated at 3.4.0). #414I think the remaining tasks are:
sizearguments that control line width and add alinewidthargumentfattenandsizeforgeom_pointrangeas described in Deprecated ggplot2 arguments #408 (comment)Deprecate user-facing `size` and `fatten` args for ggplot2 4.0 (stan-…
utkarshpawade commentedon Apr 2, 2026
hi @jgabry i did an audit of the codebase for all remaining ggplot2 v4 deprecated patterns beyond whats been resolved in #410 and #414. Here's what I found:
fattenargumentcoord_flip()theme_get()/theme_set()$access on ggplot objectsfortify()i also checked for
aes_string(),after_stat(),last_plot(),geom_errorbarh(),coord_trans(), andborders(). none of these are used in bayesplot.regarding the open questions from pr 430:
Default size when replacing fatten:
size = 2.5overshoots becausegeom_pointrange()still applies its internal fatten multiplier (default 4) on top.size = 1is worth trying first. we can compare against current output with vdiffr snapshots to calibrate.geom_linerange()+geom_point()vsgeom_pointrange(): this would sidestep the fatten multiplier entirely and give direct control over point size. more code, butsizebecomes unambiguous. worth exploring.ppc_rootogram(): heresizecontrols line width, not point size, so it should follow thesize→linewidthpath instead of the fatten/size path.utkarshpawade commentedon Apr 9, 2026
hi @jgabry about the new default
size, i ran an empirical sweep onppc_intervalsso we have actual renders to compare against the master baseline.setup: a copy of
ppc_intervalsthat uses the exact production code path (sameintervals_inner_aes,scale_color_ppc, etc.) and only varies thegeom_pointrangesize/fattenarguments. sanity-checked by rendering it with master defaults next to the realppc_intervals(y, yrep)pixel-identical. used a sparse 30-point subset ofexample_y_dataso individual dot sizes are clearly visible.size = 0.625(no fatten)0.625 * 4 = 2.5)size = 1(no fatten)size = 2.5(no fatten)geom_linerange + geom_point(size = 1.5)sizemeans what users expectso under the current
geom_pointrangeapproachsize = 0.625is the math-faithful drop-in, but it's an ugly default. the split-geom path looks like the better long-term fix from the renders,sizegets its expected ggplot2 semantics and the result is closer to baseline at any reasonable value.