Label key figures

[caldwellst]

Developed a label_key_figures() function to allow us to match the key figures style in the HDX style guide, which we are going to use in Signals. Figured better to put in here for longevity.

https://data.humdata.org/dataviz-guide/dataviz-elements/#/data-visualization/text

[hannahker]

What is the 009 indicating here? If following conventions for Semantic Versioning, we'd want to remove leading 0s.

[caldwellst]

Ha, so, that .009 was an accident, but actually what I meant was .9000. In R, it's the standard representation of a development version of the package that sits between semantic releases. This is because it's extremely common for people to access development versions directly from GitHub, so putting that in the DESCRIPTION indicates it sits between any GitHub tagged releases. See dplyr for example, and the R Packages book section on releasing describing the process.

[hannahker]

Aha! Yes, that makes sense 😄

[hannahker]

For one unfamiliar with R packaging... are these files the source for this documentation?

[zackarno]

yes thats right. The @roxygen tags which are similar to docstrings auto-generate the .Rd files which then automatically produce that documentation

[hannahker]

Nice @caldwellst! Curious about the testing workflows for this repo. How would I install the version of this package associated with this branch (like a release candidate?) to test the function? Or is there a better way to test this code locally on my side? And what impact does the R-CMD-check failure have?

[zackarno]

Nice @caldwellst! Curious about the testing workflows for this repo. How would I install the version of this package associated with this branch (like a release candidate?) to test the function? Or is there a better way to test this code locally on my side? And what impact does the R-CMD-check failure have?

@hannahker - a couple ways to do this:

1. you can git clone the repo. Then open it in Rstudio via the .Rproj file. Then checkout the relevant branch and click ctrl+shift+b to build the package. Then that version will be called when running library(gghdx)
2. Another way would just be to just install the dev version directly with the remotes.

I think i usually just do option 1 so that i can easily checkout and build different versions

[zackarno]

sweet!! i feel like i've used {numberFormattR} or some other hacky solution in the past, so it's nice to have something available right in {gghdx}.

The only thing I am not sure i understand is the name of the function... what makes them key in this context. Key makes me think of the legend key or something. If we were to stick w/ the {scales} syntax, perhaps label_number_hdx() could make sense?

[caldwellst]

Completely agree on the name change, so did that! Have also made other fixes which hopefully fix the runs on CRAN.

[caldwellst]

Nice @caldwellst! Curious about the testing workflows for this repo. How would I install the version of this package associated with this branch (like a release candidate?) to test the function? Or is there a better way to test this code locally on my side? And what impact does the R-CMD-check failure have?

There is no impact of an R-CMD-check failure in that you can keep the package as is without it passing, but the check emulates the automated checks done when packages release to CRAN, so if you are failing, always best to fix it! In this case, the failure only occurs deep within {ggplot2} and only on R 3.6 on Windows, so not necessarily critical for us and very unclear why it is occurring. It also is not related to this PR but at least we can see we succeed in all latest releases.

[hannahker]

Thanks for clarifying the various points! Tested the new function locally and looks great to me.