-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support scale functions in packages not attached via scale_type() #4705
Comments
+1. There's less trouble with geoms and other kinds of functions because you need to call them explicitly. Scales, however, most of the time work automagically, so it would be great to have a way to tell ggplot2 how to find them independently of whether the user attaches third-party packages or not. This could be done via some dynamic registration mechanism (similar to dynamic registration of S3 methods), but the proposal by @krlmlr, via |
@thomasp85 do you think we could get this in the next minor release? |
sure |
Alternatively, if no scale was found in an attached package we could look through In either case, I thinking seeing a concrete implementation in a PR would be useful. |
+1. I'm running in to similar problems which I've been trying to debug. Just commenting to note #4799 fixed things for me. |
This is a workaround until tidyverse/ggplot2#4705 is resolved. Utilise the same approach as the units package and error if scale_type is called without grates being attached (see r-quantities/units@a8f896f).
This is from r-lib/pillar#404 that implements
scale_type.pillar_num()
(returning"num"
) andscale_x_num()
andscale_y_num()
. The scales become available only after the pillar package is attached, see below. This seems to be due to how scale lookup is performed inggplot2/R/scale-type.R
Line 13 in c89c265
Should we allow
scale_type()
to return a reference to an environment where to (also) look for scale functions? Perhaps if ourscale_type()
returns"pillar::num"
, or as an attribute to the value returned byscale_type()
?Created on 2021-12-28 by the reprex package (v2.0.1)
r-quantities/units#294 is also affected, CC @Enchufa2.
The text was updated successfully, but these errors were encountered: